This Tech Tip outlines how enterprise defenders can mitigate the risks of the curl and libcurl  vulnerabilities in their environments.

Security teams don’t have to swing into crisis mode to address the recently fixed vulnerabilities in the command-line tool curl and the libcurl library, but that doesn't mean they don't have to worry about identifying and remediating impacted systems. If the systems are not immediately exploitable, security teams have some time to make those updates.

This Tech Tip aggregates guidance on what security teams need to do to ensure they aren't at risk.

A foundational networking tool for Unix and Linux systems, cURL is used in command lines and scripts to transfer data. Its prevalence is due to the fact that it is used as both a standalone utility (curl) as well as a library that is included in many different types of applications (libcurl). The libcurl library, which allows developers to access curl APIs from their own code, can be introduced directly into the code, used as a dependency, used as part of an operating system bundle, included as part of a Docker container, or installed on a Kubernetes cluster node.

**What Is CVE-2023-38545?**

The high severity vulnerability affects curl and libcurl versions 7.69.0 to 8.3.0, and the low severity vulnerability impacts libcurl versions 7.9.1 to 8.3.0. However, the vulnerabilities cannot be exploited under default conditions. An attacker trying to trigger the vulnerability would need to point curl at a malicious server under the attacker’s control, make sure curl is using a SOCKS5 proxy using proxy-resolver mode, configure curl to automatically follow redirects, and set the buffer size to a smaller size.

According to Yair Mizrahi, a senior security researcher at JFrog, the libcurl library is vulnerable only if the following environment variables are set: _CURLOPT\_PROXYTYPE_  set to type _CURLPROXY\_SOCKS5\_HOSTNAME_; or _CURLOPT\_PROXY_ or _CURLOPT\_PRE\_PROXY_  set to scheme _socks5h://_. The library is also vulnerable if one of the proxy environment variables is set to use the _socks5h://_ scheme. The command-line tool is vulnerable only if it is executed with the _\-socks5-hostname_ flag, or with _\--proxy_ (-x) or _\--preproxy_ set to use the scheme _socks5h://_. It is also vulnerable if curl is executed with the affected environment variables.

“The set of pre-conditions needed in order for a machine to be vulnerable (see previous section) is more restrictive than initially believed. Therefore, we believe the vast majority of curl users won’t be affected by this vulnerability,” Mizrahi wrote in the analysis.

**Scan the Environment for Vulnerable Systems**

The first thing organizations need to do is to scope their environments to identify all systems using curl and libcurl to assess whether those preconditions exist. Organizations should inventory their systems and evaluate their software delivery processes using software composition analysis tools for code, scanning containers, and application security posture management utilities, notes Alex Ilgayev, head of security research at Cycode. Even though the vulnerability does not affect every implementation of curl, it would be easier to identify the impacted systems if the team starts with a list of potential locations to look.

The following commands identify which versions of curl are installed:

_Linux/MacOS:_

_find / -name curl 2>/dev/null -exec echo "Found: {}" \\; -exec {} --version \\;_

_Windows:_

_Get-ChildItem -Path C:\\ -Recurse -ErrorAction SilentlyContinue -Filter curl.exe | ForEach-Object { Write-Host "Found: $($\_.FullName)"; & $\_.FullName --version }_

GitHub has a query to run in Defender for Endpoint to identify all devices in the environment that have curl installed or use curl. Qualys has published its rules for using its platform.

Organizations using Docker containers or other container technologies should also scan the images for vulnerable versions. A sizable number of rebuilds are expected, particularly in docker images and similar entities that incorporate liburl copies. Docker has pulled together a list of instructions on assessing all images.

_To find existing repositories:_

_docker scout repo enable --org <org-name> <org-name>/scout-demo_

_To analyze local container images:_

_docker scout policy \[IMAGE\] --org \[ORG\]_

This issue highlights the importance of keeping meticulous track of all open source software being used in an organization, according to Henrik Plate, a security researcher at Endor Labs.

“Knowing about all the uses of curl and libcurl is the prerequisite for assessing the actual risk and taking remediation actions, be it patching curl, restricting access to affected systems from untrusted networks, or implementing other countermeasures,” Plate said.

If the application comes with a software bill of materials, that would be a good place to start looking for instances of curl, adds John Gallagher, vice president of Viakoo Labs.

Just because the flaws are not exploitable doesn’t mean the updates are not necessary. Patches are available directly for curl and libcurl, and many of the operating systems (Debian, Ubuntu, Red Hat, etc.) have also pushed fixed versions. Keep an eye out for security updates from other applications, as libcurl is a library used by many operating systems and applications.

One workaround until the updates can be deployed is to force curl to use local hostname resolving when connecting to a SOCKS5 proxy, according to JFrog’s Mizrahi. This syntax uses the socks5 scheme and not socks5h: _curl -x socks5://someproxy.com_. In the library, replace the environment variable _CURLPROXY\_SOCKS5\_HOSTNAME_ with _CURLPROXY\_SOCKS5_.

According to Benjamin Marr, a security engineer at Intruder,  security teams should be monitoring curl flags for excessive large strings, as that would indicate the system had been compromised. The flags are _\--socks5-hostname_, or _\--proxy_ or _\--preproxy_ set to use the scheme _socks5h://_.

How to Scan Your Environment for Vulnerable Versions of Curl

A memory leak in tsMuxer version git-2539d07 allows attackers to cause a Denial of Service (DoS) via a crafted MP4 file.

**tsMuxer****Vision**

This project is for tsMuxer - a transport stream muxer for remuxing/muxing elementary streams. This is very useful for transcoding and this project is used in other products such as Universal Media Server.

EVO/VOB/MPG, MKV/MKA, MP4/MOV, TS, M2TS to TS to M2TS.

Supported video codecs H.264/AVC, H.265/HEVC, H.266/VVC (Alpha release), VC-1, MPEG2. Supported audio codecs AAC, AC3 / E-AC3(DD+), DTS/ DTS-HD - please note TrueHD must have the AC3 core intact.

Some of the major features include:

*   Ability to set muxing fps manually and automatically
*   Ability to change level for H.264 streams
*   Ability to shift a sound tracks
*   Ability to extract DTS core from DTS-HD
*   Ability to join files
*   Output/Author to compliant Blu-ray Disc or AVCHD
*   Blu-ray 3D support

**Ethics**

This project operates under the W3C's Code of Ethics and Professional Conduct:

> W3C is a growing and global community where participants choose to work together, and in that process experience differences in language, location, nationality, and experience. In such a diverse environment, misunderstandings and disagreements happen, which in most cases can be resolved informally. In rare cases, however, behavior can intimidate, harass, or otherwise disrupt one or more people in the community, which W3C will not tolerate.
> 
> A Code of Ethics and Professional Conduct is useful to define accepted and acceptable behaviors and to promote high standards of professional practice. It also provides a benchmark for self evaluation and acts as a vehicle for better identity of the organization.

We hope that our community group act according to these guidelines, and that participants hold each other to these high standards. If you have any questions or are worried that the code isn't being followed, please contact the owner of the repository.

**Language**

tsMuxer is written in C++. It can be compiled for Windows, Linux and Mac.

**History**

This project was created by Roman Vasilenko, with the last public release 20th January 2014. It was open sourced on 23rd July 2019, to aid the future development.

**Installation**

Please see INSTALLATION.md for installation instructions.

**Usage**

Please see USAGE.md for usage instructions.

**Todo**

The following is a list of changes that will need to be made to the original source code and project in general:

*   the program doesn't support MPEG-4 ASP, even though MPEG-4 ASP is defined in the TS specification
*   no Opus audio support
*   several muxing bugs when muxing a HEVC/UHD stream - results in an out-of-sync stream
*   has issues with 24-bit DTS Express
*   issues with the 3D plane lists when there are mismatches between the MPLS and M2TS

**Contributing**

We’re really happy to accept contributions from the community, that’s the main reason why we open-sourced it! There are many ways to contribute, even if you’re not a technical person.

We’re using the infamous simplified Github workflow to accept modifications (even internally), basically you’ll have to:

*   create an issue related to the problem you want to fix (good for traceability and cross-reference)
*   fork the repository
*   create a branch (optionally with the reference to the issue in the name)
*   hack hack hack
*   commit incrementally with readable and detailed commit messages
*   submit a pull-request against the master branch of this repository

We’ll take care of tagging your issue with the appropriated labels and answer within a week (hopefully less!) to the problem you encounter.

If you’re not familiar with open-source workflows or our set of technologies, do not hesitate to ask for help! We can mentor you or propose good first bugs (as labeled in our issues). Also welcome to add your name to Credits section of this document.

All pull requests must pass code style checks which are executed with clang-format version 9. Therefore, it is advised to install an appropriate commit hook (for example this one) to your local repository in order to commit properly formatted code right away.

**Submitting Bugs**

You can report issues directly on Github, that would be a really useful contribution given that we lack some user testing on the project. Please document as much as possible the steps to reproduce your problem (even better with screenshots).

**Building**

For full details on building tsMuxer for your platform please see the document on COMPILING.

**Testing**

The very rough and incomplete testing document is available at TESTING.md.

**Financing**

We are not currently accepting any kind of donations and we do not have a bounty program.

**Sponsorships**

The project is part of the MacStadium Open Source Program to create native Apple Silicon executables for Mac OS.

**Versioning**

Version numbering follows the Semantic versioning approach.

**License**

We’re using the Apache 2.0 license for simplicity and flexibility. You are free to use it in your own project.

**Credits**

**Original Author** Roman Vasilenko (physic)

**Contributors**

*   Daniel Bryant (justdan96)
*   Daniel Kozar (xavery)
*   Jean Christophe De Ryck (jcdr428)
*   Stephen Hutchinson (qyot27)
*   Koka Abakum (abakum)
*   Alexey Shidlovsky (alexls74)
*   Lonely Crane (lonecrane)
*   Markus Feist (markusfeist)

For sake of brevity I am including anyone who has merged a pull request!

CVE-2023-45511: GitHub - justdan96/tsMuxer: tsMuxer is a transport stream muxer for remuxing/muxing elementary streams, EVO/VOB/MPG, MKV/MKA, MP4/MOV, TS, M2TS to TS to M2TS. Supported video codecs H.264/AVC, H.265/H

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

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

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

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

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

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

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

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

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

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

Subscribe

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

**PRESS RELEASE**

**WATERLOO, ON, Oct. 10,2023 / PRNewswire/--** BlackBerry Limited (NYSE: BB; TSX: BB), the pioneer of enterprise mobility management, today announced two major new Unified Endpoint Management (UEM) innovations — BlackBerry UEM at the edge and BlackBerry UEM for the IoT.

BlackBerry® UEM software is used for managing, monitoring, and securing all of an organization's end-user devices. Taking BlackBerry UEM to the edge will enhance enterprise productivity and employee experience by placing workloads close to the end user and their device for ultra-low latency connectivity, while maintaining the highest security standards that customers rely on and trust BlackBerry to deliver – in testing users saw up to 87% decrease in latency. The solution brings the BlackBerry Network Operations Center (NOC), the company's unique secure connectivity infrastructure, to the edge and integrates with AWS Local Zones and Availability Zones to securely place compute, storage, and other services where data is being generated and consumed. BlackBerry UEM at the edge is compatible with BlackBerry UEM on-prem and cloud.

BlackBerry UEM for the Internet of Things (IoT) will expand unified endpoint management to IoT devices enabling organizations to realize the vast benefits of the IoT and reduce unknown risks in their environment. The solution integrates BlackBerry UEM with AWS IoT Greengrass, an open source edge runtime and cloud service used on millions of IoT endpoints across the connected world – in factories, vehicles, healthcare, enterprises – to provide IoT endpoint visibility and management and empower IT teams. Advancing the company's convergence vision, this new addition to BlackBerry UEM will enable organizations to seamlessly and securely inventory and manage their IT and IoT endpoints from a single console.

"BlackBerry founded and has been a leader in the enterprise mobility management market for over twenty years. We are once again revolutionizing the market, by leapfrogging the industry in endpoint management innovation and paving the way for convergence," said Neelam Sandhu, Chief Elite Customer Success Officer, BlackBerry. "It has been wonderful to collaborate with AWS to develop BlackBerry UEM at the edge and BlackBerry UEM for the IoT, to enable our customers to unlock new business value through digital technologies, which offer the potential to transform and advance every aspect of the connected world, spanning how we live and work." 

"IoT has advanced over the past years across different industries – automotive, enterprise, medical, manufacturing. The convergence of the IoT with security at the forefront of the conversation is now emerging as a must-have for the connected world. Bridging systems in the cloud provides scale, consistency, and flexibility to organizations to access data across the IoT and developers to innovate to deliver new value. AWS is delighted to collaborate with BlackBerry on UEM edge and IoT solutions to deliver unified and innovative endpoint management solution for the future of the connected world," said Dr. Sarah Cooper, General Manager for Industry Products at AWS.

The IoT is a foundational pillar of the future of digital transformation and unlocks new business opportunities for organizations by dramatically extending the reach of information technology. The value of enterprise IoT is largely untapped today due to the heavy compute requirements of the IoT and the complexity of the IoT network. Edge computing addresses the increasing demand for real-time data processing and analysis, and increased endpoint visibility provides valuable situational awareness and security benefits, enabling organizations to easily integrate IoT into their IT strategies. 

BlackBerry UEM holds the most security certifications in the industry and is the only UEM product to be named 2023 Customers Choice by Gartner® Peer Insights™.

AWS provides reliable, scalable, and inexpensive cloud computing services to organizations around the world. For more information on AWS products click here.

For more information on BlackBerry UEM at the edge or BlackBerry UEM for the IoT, including general availability dates, register for BlackBerry Summit, taking place on October 17, where speakers from industry, enterprise and BlackBerry will reveal the future of IoT, IT and Cybersecurity and showcase the latest BlackBerry innovations.

**About BlackBerry**

BlackBerry (NYSE: BB; TSX: BB) provides intelligent security software and services to enterprises and governments around the world. The company secures more than 500M endpoints including over 235M vehicles. Based in Waterloo, Ontario, the company leverages AI and machine learning to deliver innovative solutions in the areas of cybersecurity, safety, and data privacy solutions, and is a leader in the areas of endpoint security, endpoint management, encryption, and embedded systems. BlackBerry's vision is clear - to secure a connected future you can trust.

For more information, visit BlackBerry.com and follow @BlackBerry.

_Trademarks, including but not limited to BLACKBERRY and EMBLEM Design are the trademarks or registered trademarks of BlackBerry Limited, and the exclusive rights to such trademarks are expressly reserved. All other trademarks are the property of their respective owners. BlackBerry is not responsible for any third-party products or services._

BlackBerry Unveils Next-Generation UEM Redefining the Endpoint Management Market

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

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

An 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

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.

Tag

#mac