Plus, many of the world’s largest cloud providers are warning of a vulnerability that attackers exploited in August to launch the largest distributed denial-of-service attack on record.

Thursday, October 12, 2023 14:10

Welcome to this week’s edition of the Threat Source newsletter. 

I didn’t feel like I wanted to write anything special or witty this week given the current events in Israel and the Gaza Strip, but I will certainly advocate for any assistance readers would like to provide to the various organizations and helpers who are trying to do some good for Israeli and Palestinian civilians right now.  

And since it’s still Cybersecurity Awareness Month, I also wanted to provide some links to various resources, blog posts and podcasts that I’ve found particularly helpful this month and I think you will, too. 

*   Countering the Rise of Ransomware (Cisco YouTube) 
*   Talos APJC Threat Update: How attackers are using AI 
*   The New Normal: How XDR is Tackling Social Engineering in Today’s World (Cisco Secure blog) 
*   CISA’s Secure Our World initiative 
*   Allied Against Hate: CISA resources for faith and community leaders 
*   Fact sheet: Improving Security of Open Source Software in Operational Technology and Industrial Control Systems 

**The one big thing **

Many of the world’s largest cloud providers are warning of a vulnerability that attackers exploited in August to launch the largest distributed denial-of-service attack on record. CVE-2023-44487, a vulnerability in the HTTP/2 protocol, was recently used to launch intensive DDoS attacks against several targets. The problem lies in the way that HTTP/2 protocol handles request cancellations or resets. When a client issues a reset for an HTTP/2 request, this consumes resources on the server as it cancels the corresponding stream. However, after issuing a reset, the client can instantly open a new stream. 

**Why do I care? **

Google said the attack in August was the heaviest DDoS assault it ever recorded at over 398 million requests per second, which the company said is more than seven times larger than any other its ever recorded. So, the sheer scale is certainly notable. If this type of attack was launched with a much larger botnet, the traffic volume could be orders of magnitude greater and have a much larger potential impact. As such, organizations are urged to patch or mitigate as quickly as possible. 

**So now what? **

Users of any products using the vulnerable protocol — individual companies like F5 and Microsoft have released individual advisories about anything that was affected — should make sure patches are implemented immediately. However, this issue is largely about appropriate DDoS mitigation techniques on your environment. A newly released Snort rule, SID 62519, can detect activity associated with this vulnerability.  

**Top security headlines of the week **

**Attackers have published the personal information of almost one million people who have Ashkenazi Jew heritage** after the adversaries breached genetic testing service 23AndMe. The list allegedly includes full names, sex and 23AndMe’s data on where their ancestry stems from. As of Wednesday morning, the company was still investigating the attackers’ claims but assumed it was authentic. Customers can learn more about their family’s heritage by providing identification data, health information, phenotype, photos and more to 23AndMe. A security researcher said the information looked authentic, and that it’s a sign that a data breach can be dangerous, even if attackers don’t end up manually breaking into a deeper layer of the network. (The Record by Recorded Future 23andMe scraping incident leaked data on 1.3 million users of Ashkenazi and Chinese descent)  

**Microsoft patched more than 100 vulnerabilities in its range of products as part of its monthly security update.** This batch included two zero-day vulnerabilities that had already been exploited in the wild and nine critical issues in the Layer 2 tunneling protocol. Meanwhile, Apple also released a security update Tuesday to fix two critical vulnerabilities in its iOS mobile operating system that were also being exploited in the wild. CVE-2023-42724 in iOS and iPadOS, has been exploited by attackers to elevate their access on a local device. Back on the Microsoft side, the company also used Patch Tuesday as an opportunity to fix security holes in their products related to the high-profile HTTP/2 protocol used to launch massive, distributed denial-of-service (DDoS) attacks earlier this year. (Talos, Krebs on Security) 

The International Committee of the Red Cross published new guidelines this week, **hoping hacktivist groups will follow during wartime to avoid affecting critical infrastructure and everyday civilians.** An increasing number of civilian hackers have become involved in international conflicts hoping to make a difference, especially in the Russia-Ukraine war and now again in Israel. The Red Cross’ new guidelines urge these groups and individuals to obey national laws, if appropriate, and follow the same set of rules for kinetic warfare that international humanitarian law (IHL) provides, and which are aimed at safeguarding “civilians, and soldiers who are no longer able to fight, from some of the horrors of war.” Some of the objectives put forth include not targeting civilian objectives, deploying any malware that may target military and civilian targets indiscriminately and adhering to these rules even if the enemy does not. (Washington Post, SecurityWeek). 

**Can’t get enough Talos? **

*   Talos Takes Ep. #157: Cybersecurity Awareness Month: The best practices for implementing multi-factor authentication 
*   Qakbot hackers now pushing Cyclops/Ransom Knight ransomware, Cisco says 
*   Qakbot hackers are still spamming victims despite FBI takedown 
*   Qakbot Attackers Remain Alive and Quacking, Researchers Find 
*   Researcher Spotlight: How looking at decades of spam led Jaeson Schultz from Y2K to the metaverse and cryptocurrency 
*   Vulnerability Roundup: 10 zero-day vulnerabilities in industrial cell router could lead to code execution, buffer overflow 

**Upcoming events where you can find Talos **

**ATT&CKcon 4.0** **(Oct. 24 - 25)** 

_McLean, Virginia_ 

> Nicole Hoffman and James Nutland discuss the MIRE ATT&CK framework in “One Leg to Stand on: Adventures in Adversary Tracking with ATT&CK.” Even though ATT&CK has become an industry standard for cyber threat intelligence reporting, all too often, techniques are thrown at the bottoms of reports and blogs without any context never to be seen again after dissemination. This is not useful for intelligence producers or consumers. In this presentation, Nicole and James will show analysts how to use ATT&CK as a guideline for creating a contextual knowledge base for adversary tracking. 

**misecCON** **(Nov. 17)** 

_Lansing, Michigan_ 

> Terryn Valikodath from Talos Incident Response will deliver a talk providing advice on the best ways to conduct analysis, learning from his years of experience (and mishaps). He will speak about the everyday tasks he and his Talos IR teammates must go through to properly perform analysis. This talk covers topics such as planning, finding evil, recording findings, correlation and creating your own timelines. 

**Most prevalent malware files from Talos telemetry over the past week **

**SHA 256: a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91**  
**MD5:** 7bdbd180c081fa63ca94f9c22c457376  
**Typical Filename:** c0dwjdi6a.dll  
**Claimed Product:** N/A  
**Detection Name:** Trojan.GenericKD.33515991

**SHA 256: d5219579eec1819d52761730a72ce7a95ee3f598fcfd9a4b86d1010ea103e827**  
**MD5:** bf357485cf123a72a46cc896a5c4b62d  
**Typical Filename:** bf357485cf123a72a46cc896a5c4b62d.virus  
**Claimed Product:** N/A  
**Detection Name:** W32.Auto:d5219579ee.in03.Talos

**SHA 256: 975517668a3fe020f1dbb1caafde7180fd9216dcbf0ea147675ec287287f86aa**   
**MD5:** 9403425a34e0c78a919681a09e5c16da   
**Typical Filename:** vincpsarzh.exe   
**Claimed Product:** N/A   
**Detection Name:** Win.Dropper.Scar::tpd 

**SHA 256:** 4c3c7be970a08dd59e87de24590b938045f14e693a43a83b81ce8531127eb440   
**MD5:** ef6ff172bf3e480f1d633a6c53f7a35e   
**Typical Filename:** iizbpyilb.bat   
**Claimed Product:** N/A    
**Detection Name:** Trojan.Agent.DDOH 

**SHA 256:** 7f66d4580871e3ee6a35c8fef6da7ab26a93ba36b80279625328aaf184435efa   
**MD5:** e9a6b1346d1a2447cabb980f3cc5dd27   
**Typical Filename:** профиль 10 класс.exe   
**Claimed Product:** N/A   
**Detection Name:** Application\_Blocker

Top resources for Cybersecurity Awareness Month

By Deeba Ahmed
LinkedIn and Microsoft users, watch out for this phishing scam!
This is a post from HackRead.com Read the original post: LinkedIn Phishing Scam Exploits Smart Links to Steal Microsoft Accounts

Cofense cybersecurity researchers have noticed a sudden uptick in phishing messages sent via LinkedIn, as they observed around 800 emails sent between July and August 2023.

****_KEY FINDINGS_****

*   **A new LinkedIn phishing scam targets users to steal their Microsoft account login credentials.**

*   **Phishing actors are exploiting LinkedIn’s Smart Link feature to evade email security mechanisms and redirect users to phishing pages designed to steal financial data.**

*   **The Smart Links feature is part of LinkedIn Sales Navigator and Enterprise and allows users to send up to 15 documents with a single trackable link.**

*   **Phishing actors are interested in exploiting Smart Links to make their phishing emails seem legitimate and appear to be sent by a trusted source apart from bypassing email protections.**

*   **This campaign targets diverse industries, but the most prominent targets are the finance and manufacturing sectors.**

If you use **LinkedIn** to connect with your colleagues or industry experts, then you should feel alert because, in the newly discovered phishing campaign, threat actors are abusing a legitimate feature of LinkedIn to send authentic-looking phishing emails.

According to a report from email security firm Cofense, the feature exploited in this campaign is **Smart Links**, part of the LinkedIn Sales Navigator and Enterprise service. Phishers are abusing it to steal payment data. They exploit Smart Links to bypass email protection mechanisms and deliver malicious lures into the email inboxes of Microsoft users. Cofense

Cofense cybersecurity researchers have noticed a sudden uptick in phishing messages sent via LinkedIn, as they observed around 800 emails sent between July and August 2023. These emails were sent through 80 unique Smart Links and mostly lured users with payments, essential documents, security notifications, or recruitment-related messages.

According to Cofense’s blog post, all the messages contained an embedded link/button to redirect the victim to a malicious website where the attackers compel them to give away personal/financial data or login credentials. 

The report’s author, Cofense cyber threat intelligence analyst Nathaniel Raymond, noted that this campaign most probably exploits newly created or compromised business accounts on LinkedIn to deliver malicious lures and forces users to provide their Microsoft account details.

Clicking on viewing document opens a fake Microsoft login page that steals credentials (Image credit: Cofense)

For your information, this feature allows businesses to promote ads or websites and redirect users to their desired domains. This tool lets business account holders contact LinkedIn users via trackable ‘smart’ links. The sender can track who interacted with their messages and in what manner. Therefore, this tool is ideal for pitch testing and enhancing the process.

The smart link includes the LinkedIn domain with a parameter and an eight-alphanumeric character ID. However, adversaries have added new information, such as the recipient’s email ID, to autofill the phishing page the victim gets redirected to.

Employees at a wide range of organizations are targeted in this campaign, including manufacturing, financial, energy, construction, insurance, health, mining, consumer goods, and technology. But manufacturing and financial organizations were the top targets.

> _“Despite finance and manufacturing having higher volumes, it can be concluded that this campaign was not a direct attack on any one business or sector but a blanket attack to collect as many credentials as possible using LinkedIn business accounts and smart links to carry out the attack.”_
> 
> Nathaniel Raymond – Cofense

To protect yourself against malicious phishing links, you must be wary of emails from unknown users, even if the email came from an authentic source or domain. Only click on links embedded in the email if you believe the email is legit, and if you are unsure, a good idea is to contact the sender directly to verify it. Use a reliable password manager to create unique passwords for online accounts and **enable 2FA** on all of them.

1.  New LinkedIn phishing campaign found using Google Forms
2.  Fake LinkedIn job offers scam spreading More\_eggs backdoor
3.  Iranian Hackers Posed as Israelis in Targeted LinkedIn Phishing Attack
4.  Ducktail Malware Exploits LinkedIn to Hack Facebook Business Accounts
5.  Hackers Used Fake LinkedIn Job Offer to Hack Off $625M from Axie Infinity

LinkedIn Phishing Scam Exploits Smart Links to Steal Microsoft Accounts

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

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

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

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

Government security processes are often viewed as tedious and burdensome — but applying the lessons learned from them is imperative for private industry to counter a nation-state threat.

The private sector's utility, telecom, banking, transportation, and medical networks have become a part of physical, mental, and economic well-being in the modern world. They are also under unprecedented threat from state actors — recently underscored by the unclassified summary of the Department of Defense's cybersecurity strategy, which stated that China "steals technology secrets and undermines the DIB \[defense industrial base\]," and that, in the event of conflict, China "likely intends to launch destructive cyber attacks against the U.S. Homeland." The Director of National Intelligence's assessment further elaborated that "China is almost certainly capable of launching cyberattacks that could disrupt critical infrastructure services within the United States, including against oil and gas pipelines, and rail systems."

The DIB and critical infrastructure are under clear threat from our near-peer competitors and would do well to apply select best practices from US government classified systems to protect their own crown jewels.

**Understand Where and How Protected Enclaves and the Internet Intersect**

Whether in the operational technology (OT) networks of utilities, the research and development enclaves of pharmaceutical networks, or the medical equipment networks of hospitals, some parts of networks need to be more secure than others. But even in utilities' OT networks, which contain a critical mass of potentially vulnerable legacy technology, total segmentation is a myth, and for good reason: Companies increasingly require the power of big data analytics, integrations with Internet-connected financial systems, and similar services to operate an effective business.

A sound approach to risk management in connecting protected enclaves to broader IT networks can be found in a relatively obscure section of National Security Memorandum 8 (NSM-8): Cultivate visibility and rigor around the areas in which the networks overlap. By declaring that cross-domain systems — the systems responsible for connecting classified networks to unclassified networks — are "vital \[national security systems\] that require centralized visibility" and establishing the NSA's Raise the Bar program to oversee them, the US government ensured a level of consistent risk evaluation and security rigor around these inherently risky junctures in the network.

By doing the same, organizations can better manage risk and ensure a consistent approach, rather than crafty and unique but often unvetted solutions to bridge protected enclaves and the broader network. As these centralized points of visibility mature within organizations, they can also unite at an industry level via information sharing and analysis centers (ISACs) or ad hoc collaborative networks to understand best practices and technologies to minimize the risks at these critical network junctures.

**Protect the Critical Enterprise Along With Critical Infrastructure**

As alluded to above, the crown jewels of critical infrastructure organizations may be well-protected, but they are surrounded by a critical enterprise of enabling functions — HR, customer service, finance, logistics — hosted on a less-secure IT network and sometimes one step removed from the culture of security that permeates operational parts of the organization. But the threat of lateral movement within the network, whereby an adversary could compromise an employee in the critical enterprise and eventually navigate their way to more sensitive systems, renders this an unwise approach. The risk is compounded by the fact that a joint advisory by the NSA, CISA, the FBI, and others highlights China-sponsored threat actors "living off the land" within critical infrastructure networks, using native services rather than malware to evade detection once they have established a foothold.

The intelligence community has long embraced the concept of the critical enterprise by requiring that all employees — whether working operationally or in a support role — complete a thorough suitability process and protect support networks with the same rigor as their mission networks. By doing so, they not only protect their endpoints and systems at a given classification level from technical compromise but also cultivate a culture of security that renders the organization less vulnerable to human-enabled attacks, such as phishing.

While it is untenable for private sector companies to subject their employees to the same degree of scrutiny needed for a US security clearance, they can take a page from the government by securing the entire critical enterprise through training, preventive cybersecurity architecture, and a culture of security that makes the entire critical enterprise aware of the shared risks to their organization.

**Demand Security by Design**

The complexity of creating a solid cybersecurity architecture is compounded by the fact that, as CISA director Jen Easterly put it, "We've unwittingly come to accept as normal that such technology is dangerous-by-design." This has resulted in the need to deploy myriad security and network management solutions, some of which have proven dangerous by design in and of themselves.

The US government, in general, and its Department of Defense, in particular, have long exercised rigorous processes around technology readiness assessment and operational testing and evaluation. These processes, while costly and lengthy, are designed to ensure the security, maturity, and operational readiness of the technologies that will be deployed to conduct the most critical functions of the US government and support its war fighters. By exercising diligence in their procurement processes, including a strong eye toward security, US government agencies minimize the risk that their technology will be compromised.

It would be impractical to recommend that private sector organizations conduct the same degree of testing and evaluation of technology. But incorporating questions geared toward CISA's joint "Security-by-Design and -Default" principles is an appealing alternative. By moving beyond reliance on regulatory certifications (many of which test a manufacturer's processes and policies rather than the inherent security of the underlying technology), security leaders can partner with acquisition teams to increase the security of both critical infrastructure and critical enterprise. A few examples of such questions include:

*   Does your solution include multiple layers of security in case an adversary defeats one layer?
*   Do you provide and maintain a software bill of materials?
*   What hardware architectural protections are in place?
*   What is required to "harden" deployment of this solution?

Government security processes are often viewed as tedious and burdensome, but applying the lessons learned from them doesn't need to be. Taking these three key lessons and applying them to securing not only critical infrastructure but also the broader critical enterprise is imperative for private industry to counter a nation-state threat.

Protect Critical Infrastructure With Same Rigor as Classified Networks

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

#intel