Threat groups created a fake security company, "High Sierra," with faux exploits and fake profiles for security researchers on GitHub and elsewhere, aiming to get targets to install their malware.

During the month of May, an unknown threat group created a malicious GitHub repository that claimed to contain a zero-day exploit for a vulnerability in the Signal messaging app. The attackers supported the credibility of the exploit by creating a fake security company — High Sierra Cyber Security — linked to a number of made-up profiles of security researchers.

That's according to research conducted by threat intelligence firm VulnCheck, which found that the level of effort that the attacker put into create a social presence around the fake security company and the fake exploits is on a whole other level compared to what researchers have seen in the past.

"They put in a decent amount of effort into building personas, if you will, for each of these characters — these actors that who would advertise the GitHub repositories with the actual malware," VulnCheck security researcher William Vu tells Dark Reading. "So they put a lot of time and effort into building, really, a fake security company, and that, to me, is kind of new."

Targeting security researchers is rare, but has a long history. In 2021, for example, Google's Threat Analysis Group (TAG) warned that North Korea-backed hackers had created a faux research blog and multiple fake Twitter profiles. Researchers would then be asked to collaborate on vulnerability research, and those who agreed would be sent a Visual Studio project file that would run custom malware to infect the target's system, according to Google TAG's analysis. Three months later, the Cybersecurity and Infrastructure Security Agency (CISA) issued an alert about the campaign.

A similar attack — also by North Korea — targeted security researchers by using LinkedIn accounts and acting as recruiters, according to research released in March by Mandiant.

The latest attack also uses social engineering to target the supply chain, says Mike Parkin, a senior technical engineer at Vulcan Cyber, a provider of enterprise cyber-risk remediation services.

"One of the core defenses against malicious packages is for developers to actually vet the package before they download and use it, and part of that vetting process is determining if the package was created by a trustworthy source, whether commercial or otherwise," he says. "If threat actors can do a good job of faking that, they have a better chance of getting a victim to download their package and then not give it as close of an inspection as they should."

**GitHub, WhatsApp, What's Next?**

VulnCheck contacted GitHub about the project hosting the fake exploit, and the page was taken down. A day later, however, the same group created a similar page advertising a WhatsApp zero-day exploit, VulnCheck's researchers stated in the advisory. That pattern continued, and each time the company notified GitHub of a new page, it was removed but a new project page would appear. Pages offering a purported Microsoft Exchange remote code execution (RCE) bug, a Discord zero-day RCE, and others continued the cat-and-mouse game, the company stated.

In each case, instead of an exploit, a Python file in the repository would — if run by the target — download an operating-system-specific binary. While most antivirus programs detected the Windows malware that the Python script loaded, only three of the 62 Linux host-based scanners detected that binary, VulnCheck stated.

The threat actor used a variety of social media profiles to push out links to the pages. While the technique has been used as a way to convince software developers to download vulnerable or malicious components as a way of infecting the supply chain, this attack seems more likely to gain access to security professionals' own research, Vu says.

"Security researchers and testers usually have their own research, and if I were going after security researchers this way, I would be looking to obtain their cache of real zero-day exploits, and any kind of corporate IP that they might have access to," he says.

**Not the Sharpest Tool in the Toolbox**

While companies should always educate their developers about the risks that come with online code and how to best vet projects and unknown developers to determine if they are legitimate, researchers need to learn to be wary too, says Erich Kron, security awareness advocate at KnowBe4.

"Running code that others have written, especially when available in free and open websites such as GitHub, always carries some risk," he said. "In this case, researchers looking at the code may even assume that the malicious parts are simply a piece of these zero days being disclosed, when in fact it's designed to infect their own systems."

For most security researchers, a little due diligence will go a long way. A little research would likely discover that the company behind the "security research" has no track record, and that the researchers have no history in the industry, says Vulcan Cyber's Parkin.

"If a package just appeared out of nowhere, and the developers all seem to be new on the scene? Red flags," he says. "The sad thing is that this will have some negative impact on newly active researchers who may not have any history yet, but it's also easy to tell the difference between someone who doesn't have a history because they're just getting started and someone who has no history because they don't exist."

Attackers Create Synthetic Security Researchers to Steal IP

The threat actor known as ChamelGang has been observed using a previously undocumented implant to backdoor Linux systems, marking a new expansion of the threat actor's capabilities.
The malware, dubbed ChamelDoH by Stairwell, is a C++-based tool for communicating via DNS-over-HTTPS (DoH) tunneling.
ChamelGang was first outed by Russian cybersecurity firm Positive Technologies in September 2021,

Endpoint Security / Network Security

The threat actor known as **ChamelGang** has been observed using a previously undocumented implant to backdoor Linux systems, marking a new expansion of the threat actor's capabilities.

The malware, dubbed ChamelDoH by Stairwell, is a C++-based tool for communicating via DNS-over-HTTPS (DoH) tunneling.

ChamelGang was first outed by Russian cybersecurity firm Positive Technologies in September 2021, detailing its attacks on fuel, energy, and aviation production industries in Russia, the U.S., India, Nepal, Taiwan, and Japan.

Attack chains mounted by the actor have leveraged vulnerabilities in Microsoft Exchange servers and Red Hat JBoss Enterprise Application to gain initial access and carry out data theft attacks using a passive backdoor called DoorMe.

"This is a native IIS module that is registered as a filter through which HTTP requests and responses are processed," Positive Technologies said at the time. "Its principle of operation is unusual: the backdoor processes only those requests in which the correct cookie parameter is set."

The Linux backdoor discovered by Stairwell, for its part, is designed to capture system information and is capable of remote access operations such as file upload, download, deletion, and shell command execution.

What makes ChamelDoH unique is its novel communication method of using DoH, which is used to perform Domain Name System (DNS) resolution via the HTTPS protocol, to send DNS TXT requests to a rogue nameserver.

"Due to these DoH providers being commonly utilized DNS servers \[i.e., Cloudflare and Google\] for legitimate traffic, they cannot easily be blocked enterprise-wide," Stairwell researcher Daniel Mayer said.

The use of DoH for command-and-control (C2) also offers additional benefits for the threat actor in that the requests cannot be intercepted by means of an adversary-in-the-middle (AitM) attack owing to the use of the HTTPS protocol.

UPCOMING WEBINAR

🔐 Mastering API Security: Understanding Your True Attack Surface

Discover the untapped vulnerabilities in your API ecosystem and take proactive steps towards ironclad security. Join our insightful webinar!

Join the Session

This also means that security solutions cannot identify and prohibit malicious DoH requests and sever the communications, thereby turning it to an encrypted channel between a compromised host and the C2 server.

"The result of this tactic is akin to C2 via domain fronting, where traffic is sent to a legitimate service hosted on a CDN, but redirected to a C2 server via the request's Host header – both detection and prevention are difficult," Mayer explained.

The California-based cybersecurity firm said it detected a total of 10 ChamelDoH samples on VirusTotal, one of which was uploaded back on December 14, 2022.

The latest findings show that the "group has also devoted considerable time and effort to researching and developing an equally robust toolset for Linux intrusions," Mayer said.

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

ChamelDoH: New Linux Backdoor Utilizing DNS-over-HTTPS Tunneling for Covert CnC

A security issue was discovered in Kubelet that allows pods to bypass the seccomp profile enforcement. Pods that use localhost type for seccomp profile but specify an empty profile field, are affected by this issue. In this scenario, this vulnerability allows the pod to run in unconfined (seccomp disabled) mode. This bug affects Kubelet.

**Vellore Rajakumar, Sri Saran Balaji**

unread,

Jun 15, 2023, 5:41:51 AM (yesterday) Jun 15

to kubernete...@googlegroups.com, d...@kubernetes.io, kubernetes-sec...@googlegroups.com, kubernetes-se...@googlegroups.com, distributo...@kubernetes.io, kubernetes+a...@discoursemail.com

Hello Kubernetes Community, 

A security issue was discovered in Kubelet that allows pods to bypass the seccomp profile enforcement. This issue has been rated **LOW** (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N) (score: 3.4)

**Am I vulnerable?**

If you have pods in your cluster that use localhost type for seccomp profile but specify an empty profile, then you are affected by this issue. In this scenario, this vulnerability allows the pod to run in “unconfined” (seccomp disabled) mode. This bug affects Kubelet.

**Affected Versions**

*   v1.27.0 - v1.27.1
*   v1.26.0 - v1.26.4
*   v1.25.0 - v1.25.9
*   <= v1.24.13

How do I remediate this vulnerability?

To remediate this vulnerability, you should upgrade your Kubelet to one of the below mentioned versions.

**Fixed Versions**

This issue is fixed in the following versions:

*   **v1.27.2**
*   **v1.26.5**
*   **v1.25.10**
*   **V1.24.14**

To upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade/ 

**Acknowledgements**

This vulnerability was reported by Tim Allclair, and fixed by Craig Ingram.

Thank You,

Balaji on behalf of the Kubernetes Security Response Committee

CVE-2023-2431: [Security Advisory] CVE-2023-2431: Bypass of seccomp profile enforcement

A few lines of code can help you prevent accidental exposure, manage sensitive information, and maintain different configurations for various environments.

**Question: How do I keep my API keys from becoming part of someone else's GitHub search?**

**Answer:** Storing API keys directly in your code is generally not recommended due to the potential security risks. If your code is ever shared or becomes publicly accessible, anyone who sees the API key can use it, potentially leading to abuse or a security breach.

Here are several ways to store API keys securely:

*   **Environment variables:** You can store API keys in environment variables on your machine and then access these variables from your code. This method has the advantage of keeping the keys out of your code. (They are in the environment where the code runs.) It also means that the keys can be different for different environments, such as your local machine, a development server, a production server, etc.
*   **Configuration files:** You can also store API keys in a separate configuration file that is not included in your code repository. This file should be added to your _.gitignore_ file to prevent it from being committed to your repository. Be sure to add appropriate file-level permissions to this configuration file to prevent unauthorized access. In your code, you would read the API keys from this file.
*   **Secrets management systems:** For larger applications or more sensitive data, you might consider using a secrets management system. These are specialized tools, such as AWS Secrets Manager, HashiCorp's Vault, and Google's Secret Manager, that help manage access to secrets like API keys.
*   **Environment-specific configuration services:** Platforms like Heroku and Netlify have specific features or services for setting environment variables, which can be used to store API keys.
*   **Encrypted storage:** If you need to store the API keys in a database or other storage system, you should encrypt them. This way, even if someone gains access to the storage system, they won't be able to use the keys without the encryption key.

Let's take a look at how to implement the first two, the lowest-overhead of these solutions, in secure coding. I've used Python as the example language for this, though any language will have similar concepts. The advantage of Python is its simplicity and ease of use, which together with its formidable data-handling capabilities make it ideal for most uses.

**To Use Environment Variables for Storing API Keys**

Environment variables allow you to store sensitive information, such as API keys, outside of your source code. They are accessible to the application during runtime and can be easily configured on different environments (e.g., development, staging, and production).

First, set the environment variable in your system or the platform where your application is running. In a Unix-based system, you can set an environment variable using the _export_ command:

% export API\_KEY=<your\_api\_key>

Next, access the environment variable in your application's code. For example, in Python, you can access the value of an environment variable using the _os_ module:

% python import os api\_key = os.environ\['API\_KEY'\]

**To Use External Configuration Files for Storing API Keys**

Another way for the beginning developer or data scientist to store API keys is via external configuration files. These can be very useful; however, you should exclude them from the repository using _.gitignore_ or the equivalent.

First, create a configuration file, such as _config.json_, and store the API key in it:

json { "api\_key": "<your\_api\_key>" }

Next, add the configuration file to your project's _.gitignore_ (or equivalent) to ensure it's not tracked by your version control system.

Finally, load the configuration file in your application's code to access the API key. For example, in Python, you can load a JSON configuration file and access the API key like this:

import json with open('config.json') as f

config = load(f) api\_key = config\['api\_key'\]

**Lock Up Your APIs**

By using either environment variables or external configuration files, you can better protect your API keys from accidental exposure, simplify management of sensitive information, and make it easier to maintain different configurations for various environments. You should enforce proper access controls on the environment variables and configuration files to prevent unauthorized access.

As your project grows in complexity (and importance), it may be advisable to move to platforms with innate capability, such as secrets management systems or environment-specific configuration services, for storing sensitive items. However, these quick solutions help you start off on a more secure footing.

How Do I Protect My API Keys From Appearing in Search Results?

A PRC-aligned actor used a trio of custom malware to take advantage of inherent weaknesses in edge appliances.

Researchers say the recent compromise of Barracuda Networks email security gateways (ESGs) was carried out by a newly discovered Chinese APT, which used three different backdoors to exploit security failings endemic to edge devices.

According to Barracuda's timeline, on May 18, the company was alerted to anomalous traffic coming from some of its ESGs. The following day, in collaboration with security company Mandiant, it discovered a zero-day vulnerability — CVE-2023-2868 — since assigned a score of 9.8 out of 10 on the CVSS vulnerability severity scale, making it critical-rated.

In multiple statements provided to Dark Reading, Barracuda has indicated that around 5% of active ESG devices worldwide have shown evidence of compromise. The company has a global footprint, with market-share watchers pegging it as claiming around a fifth of the ESG market, with clients that include CVS Health, IBM, and McKesson. 

Now, in a report published Thursday, June 15, Mandiant has connected the campaign to a novel APT it's tracking as UNC4841, assessing "with high confidence that UNC4841 is an espionage actor behind this wide-ranging campaign in support of the People's Republic of China."

A full third of UNC4841's targets have been government organizations, and more than half are in the Americas — though "that may partially reflect the product's customer base," the researchers qualified. In many cases, the hackers collected email data not just from specific targets, but individual targets, including government officials and academics in Southeast Asia.

"They're definitely very competent," says Ben Read, Mandiant's senior manager of cyber espionage analysis, Google Cloud. "To find a vulnerability and exploit it in the ways that they have demonstrates an understanding that would have taken a lot of time and expertise to figure out. They definitely have significant funds."

**UNC4841's Many Backdoors**

UNC4841's attacks began with rudimentary phishing emails containing generic messages and broken grammar. Attached to the emails, however, were malicious tape archive (TAR) files which, when opened, exploited CVE-2023-2868, allowing the attackers to remotely execute code on target machines.

A sample UNC4841 phishing email. Source: Mandiant

Now in control of the privileges afforded to Barracuda ESGs, the attackers deployed three separate backdoors — SALTWATER, SEASPY, and SEASIDE — which each attempted to masquerade as legitimate ESG modules and services.

These backdoors "do have different capabilities, but overlap in terms of allowing for command-and-control (C2) communication to the device," explains Austin Larsen, Mandiant senior incident response consultant, Google Cloud. As he sees it, having three backdoors is a form of fault tolerance: "The actor is shown a pretty intense desire to maintain access to these devices, by establishing redundancy through multiple backdoors."

Even after its backdoors were discovered and addressed, "the threat actor reacted very quickly to any actions taken by Barracuda and Mandiant,” Larsen says. “They wanted to maintain persistence and access to these devices for as long as possible."

Together, this may explain why, even after Barracuda released a series of security patches, UNC4841's malicious activity remained ongoing. Beginning May 31, to finally rid the attackers from the appliances, the company offered to outright replace all affected ESGs at no cost to customers.

**What to Do About Edge Appliances**

Larsen points out that it's not just ESGs — edge appliances in general aren't secure enough.

"The threat that it poses is that network defenders typically don't have visibility into the underlying operating system, and so your traditional countermeasures — like EDR solutions for detection — typically don't run on these appliances," he explains. "And so, actors have realized that it's a great place to operate from, because they can typically avoid detection.”

The issues with edge appliances only mount from there. "They live on the edge of networks, so they're typically exposed in some way to the Internet and a lot of appliances are in a legacy phase at this point," he adds. "And so we're seeing that these appliances aren't quite getting the same level of attention as some more modern products and solutions, in terms of security."

But even if edge appliances themselves are vulnerable, with proper segmentation, the networks they're connected to don't have to be.

"We did identify this specific threat actor attempting to move laterally from the edge devices post-exploitation," Larsen notes. "Had these devices been in an unprivileged segment of the network, that may have prevented some of that lateral movement."

Critical Barracuda ESG Zero-Day Linked to Novel Chinese APT

Product: AndroidVersions: Android SoCAndroid ID: A-277775870

_Published June 5, 2023 | Updated June 7, 2023_

The Android Security Bulletin contains details of security vulnerabilities affecting Android devices. Security patch levels of 2023-06-05 or later address all of these issues. To learn how to check a device's security patch level, see Check and update your Android version.

Android partners are notified of all issues at least a month before publication. Source code patches for these issues have been released to the Android Open Source Project (AOSP) repository and linked from this bulletin. This bulletin also includes links to patches outside of AOSP.

The most severe of these issues is a critical security vulnerability in the System component that could lead to remote code execution over Bluetooth, if HFP support is enabled, with no additional execution privileges needed. User interaction is not needed for exploitation. The severity assessment is based on the effect that exploiting the vulnerability would possibly have on an affected device, assuming the platform and service mitigations are turned off for development purposes or if successfully bypassed.

Refer to the Android and Google Play Protect mitigations section for details on the Android security platform protections and Google Play Protect, which improve the security of the Android platform.

**Android and Google service mitigations**

This is a summary of the mitigations provided by the Android security platform and service protections such as Google Play Protect. These capabilities reduce the likelihood that security vulnerabilities could be successfully exploited on Android.

*   Exploitation for many issues on Android is made more difficult by enhancements in newer versions of the Android platform. We encourage all users to update to the latest version of Android where possible.
*   The Android security team actively monitors for abuse through Google Play Protect and warns users about Potentially Harmful Applications. Google Play Protect is enabled by default on devices with Google Mobile Services, and is especially important for users who install apps from outside of Google Play.

**2023-06-01 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2023-06-01 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated 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. Devices with Android 10 and later may receive security updates as well as Google Play system updates.

**Framework**

The most severe vulnerability in this section could lead to remote code execution with no additional execution privileges needed. User interaction is needed for exploitation.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2023-21127

A-275418191

RCE

Critical

11, 12, 12L, 13

CVE-2023-21126

A-271846393 \[2\] \[3\]

EoP

High

13

CVE-2023-21128

A-272042183

EoP

High

11, 12, 12L, 13

CVE-2023-21129

A-274759612 \[2\]

EoP

High

11, 12, 12L, 13

CVE-2023-21131

A-265015796

EoP

High

11, 12, 12L, 13

CVE-2023-21139

A-271845008 \[2\] \[3\]

EoP

High

13

CVE-2023-21105

A-261036568

ID

High

11, 12, 12L, 13

CVE-2023-21136

A-246542285

DoS

High

11, 12, 12L, 13

CVE-2023-21137

A-246541702

DoS

High

11, 12, 12L, 13

CVE-2023-21143

A-268193777

DoS

High

11, 12, 12L, 13

**System**

The most severe vulnerability in this section could lead to remote code execution over Bluetooth, if HFP support is enabled, with no additional execution privileges needed. User interaction is not needed for exploitation.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2023-21108

A-239414876

RCE

Critical

11, 12, 12L, 13

CVE-2023-21130

A-273502002

RCE

Critical

13

CVE-2023-21115

A-258834033

EoP

High

11, 12, 12L

CVE-2023-21121

A-205460459

EoP

High

11, 12

CVE-2023-21122

A-270050191

EoP

High

11, 12, 12L, 13

CVE-2023-21123

A-270050064

EoP

High

11, 12, 12L, 13

CVE-2023-21124

A-265798353 \[2\] \[3\] \[4\]

EoP

High

11, 12, 12L, 13

CVE-2023-21135

A-260570119 \[2\]

EoP

High

11, 12, 12L, 13

CVE-2023-21138

A-273260090

EoP

High

11, 12, 12L, 13

CVE-2023-21095

A-242704576

ID

High

12L, 13

CVE-2023-21141

A-262244249

ID

High

11, 12, 12L, 13

CVE-2023-21142

A-262243665

ID

High

11, 12, 12L, 13

CVE-2023-21144

A-252766417

DoS

High

11, 12, 12L, 13

**2023-06-05 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2023-06-05 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated 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.

**Arm components**

These vulnerabilities affect Arm components and further details are available directly from Arm. The severity assessment of these issues is provided directly by Arm.

    

CVE

References

Severity

Subcomponent

CVE-2022-22706  

A-225040268 \*

High

Mali

CVE-2022-28349  

A-278616909 \*

High

Mali

CVE-2022-46781  

A-267242697 \*

High

Mali

**Imagination Technologies**

These vulnerabilities affect Imagination Technologies components and further details are available directly from Imagination Technologies. The severity assessment of these issues is provided directly by Imagination Technologies.

    

CVE

References

Severity

Subcomponent

CVE-2021-0701  

A-277775870 \*

High

PowerVR-GPU

CVE-2021-0945  

A-278156680 \*

High

PowerVR-GPU

**Unisoc components**

These vulnerabilities affect Unisoc components and further details are available directly from Unisoc. The severity assessment of these issues is provided directly by Unisoc.

    

CVE

References

Severity

Subcomponent

CVE-2022-48390  

A-278796976  
U-2055602 \*

High

Android

CVE-2022-48392  

A-278775990  
U-2193456 \*  
U-2056224 \*

High

Android

CVE-2022-48438  

A-278801630  
U-2179935 \*

High

Kernel/Android

CVE-2022-48391  

A-278775987  
U-2055602 \*

High

Android

**Widevine DRM**

These vulnerabilities affect Widevine DRM components and further details are available directly from Widevine DRM. The severity assessment of these issues is provided directly by Widevine DRM.

    

CVE

References

Severity

Subcomponent

CVE-2023-21101  

A-258189255 \*

High

widevine

CVE-2023-21120  

A-258188673 \*

High

Hardware DRM

**Qualcomm components**

These vulnerabilities affect Qualcomm components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm.

    

CVE

References

Severity

Subcomponent

CVE-2022-33292  

A-250627197  
QC-CR#3152855

High

Kernel

CVE-2023-21656  

A-271879673  
QC-CR#3346781

High

WLAN

CVE-2023-21657  

A-271880369  
QC-CR#3344305

High

Audio

CVE-2023-21669  

A-271892276  
QC-CR#3346764

High

WLAN

CVE-2023-21670  

A-276750663  
QC-CR#3425942 \[2\] \[3\]

High

Display

**Qualcomm closed-source components**

These vulnerabilities affect Qualcomm closed-source components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm.

    

CVE

References

Severity

Subcomponent

CVE-2022-33257  

A-245402340 \*

Critical

Closed-source component

CVE-2022-40529  

A-261470065 \*

Critical

Closed-source component

CVE-2022-22060  

A-261470067 \*

High

Closed-source component

CVE-2022-33251  

A-245403689 \*

High

Closed-source component

CVE-2022-33264  

A-245611823 \*

High

Closed-source component

CVE-2022-40516  

A-261468731 \*

High

Closed-source component

CVE-2022-40517  

A-261470729 \*

High

Closed-source component

CVE-2022-40520  

A-261468681 \*

High

Closed-source component

CVE-2022-40521  

A-261471027 \*

High

Closed-source component

CVE-2022-40523  

A-261468047 \*

High

Closed-source component

CVE-2022-40533  

A-261470447 \*

High

Closed-source component

CVE-2022-40536  

A-261468732 \*

High

Closed-source component

CVE-2022-40538  

A-261468697 \*

High

Closed-source component

CVE-2023-21628  

A-268059669 \*

High

Closed-source component

CVE-2023-21658  

A-271879161 \*

High

Closed-source component

CVE-2023-21659  

A-271879660 \*

High

Closed-source component

CVE-2023-21661  

A-271880271 \*

High

Closed-source component

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

To learn how to check a device's security patch level, see Check and update your Android version.

*   Security patch levels of 2023-06-01 or later address all issues associated with the 2023-06-01 security patch level.
*   Security patch levels of 2023-06-05 or later address all issues associated with the 2023-06-05 security patch level and all previous patch levels.

Device manufacturers that include these updates should set the patch string level to:

*   \[ro.build.version.security\_patch\]:\[2023-06-01\]
*   \[ro.build.version.security\_patch\]:\[2023-06-05\]

For some devices on Android 10 or later, the Google Play system update will have a date string that matches the 2023-06-01 security patch level. Please see this article for more details on how to install security updates.

**2\. Why does this bulletin have two security patch levels?**

This bulletin has two security patch levels so that Android partners have the flexibility to fix a subset of vulnerabilities that are similar across all Android devices more quickly. Android partners are encouraged to fix all issues in this bulletin and use the latest security patch level.

*   Devices that use the 2023-06-01 security patch level must include all issues associated with that security patch level, as well as fixes for all issues reported in previous security bulletins.
*   Devices that use the security patch level of 2023-06-05 or newer must include all applicable patches in this (and previous) security bulletins.

Partners are encouraged to bundle the fixes for all issues they are addressing in a single update.

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

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

**5\. 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 corresponding reference ID. The update for that issue is generally contained in the latest binary drivers for Pixel devices available from the Google Developer site.

**6\. Why are security vulnerabilities split between this bulletin and device / partner security bulletins, such as the Pixel bulletin?**

Security vulnerabilities that are documented in this security bulletin are required to declare the latest security patch level on Android devices. Additional security vulnerabilities that are documented in the device / partner security bulletins are not required for declaring a security patch level. Android device and chipset manufacturers may also publish security vulnerability details specific to their products, such as Google, Huawei, LGE, Motorola, Nokia, or Samsung.

**Versions**

  

Version

Date

Notes

1.0

June 5, 2023

Bulletin Published

1.1

June 7, 2023

Bulletin revised to include AOSP links

CVE-2021-0701: Android Security Bulletin—June 2023

Purle Devloper Panel version 1.0 suffers from an insecure direct object reference vulnerability that allows an unauthenticated user to update passwords.

    ====================================================================================================================================| # Title     : Purle Devloper Panel ver 1.0 Unauthorized administrative access Vulnerability                                      || # Author    : indoushka                                                                                                          || # Tested on : windows 10 Français V.(Pro) / browser : Mozilla firefox 102.0.1(64-bit)                                            | | # Vendor    : http://www.njmweb.we.bs/Purple10/PURPLEV10.zip                                                                     |  | # Dork      : "Purle Devloper Panel"                                                                                             |====================================================================================================================================poc :[+] an unauthenticated access allow you to update password.[+] Dorking İn Google Or Other Search Enggine.[+] Use payload : /user_update.php[+] https://127.0.0.1/purple.iprebrandsapp/user_update.phpGreetings to :=========================================================================================================================                                                                                                                                      |jericho * Larry W. Cashdollar * brutelogic* hyp3rlinx* 9aylas * shadow_00715 * LiquidWorm* moncet                                     |                                                                                                                                              |=======================================================================================================================================

Purle Devloper Panel 1.0 Insecure Direct Object Reference

Ptclab version 3.5 appears to leave default credentials installed after installation.

    ====================================================================================================================================| # Title     : Ptclab V3.5 Insecure Settings Vulnerability                                                                        || # Author    : indoushka                                                                                                          || # Tested on : windows 10 Français V.(Pro) / browser : Mozilla firefox 108.0(64-bit)                                              | | # Vendor    : https://viserlab.com                                                                                               |  | # Dork      : "Every balance subtracting transactions need OTP verification so You can feel safe about your funds."              |====================================================================================================================================poc :[+] The vulnerability is about leaving the default settings    During the installation of the script and using the default username and password  [+] Dorking İn Google Or Other Search Enggine.[+] Use Payload : user=admin  & pass= admin[+] https://127.0.0.1/scriptviserlabcom/ptclab/Greetings to :=========================================================================================================================                                                                                                                                      |jericho * Larry W. Cashdollar * brutelogic* hyp3rlinx* 9aylas * shadow_00715 * LiquidWorm* moncet                                     |                                                                                                                                              |=======================================================================================================================================

Ptclab 3.5 Insecure Settings

phpFK version 8.0 suffers from a cross site scripting vulnerability.

**phpFK 8.0 Cross Site Scripting**

Posted Jun 15, 2023

Authored by indoushka

phpFK version 8.0 suffers from a cross site scripting vulnerability.

tags | exploit, xss

SHA-256 | 485c60ad53bb4abb98ff8bd8586f25cee5d5a57abf5f55c1615b45b7b607c8e0

Download | Favorite | View

**phpFK 8.0 Cross Site Scripting**

    ====================================================================================================================================| # Title     : phpFK v8.0 version XSS Vulnerability                                                                               || # Author    : indoushka                                                                                                          || # Tested on : windows 10 Français V.(Pro) / browser : Mozilla firefox 68.0(32-bit)                                               | | # Vendor    : https://www.frank-karau.de/demo-forum/                                                                             |  | # Dork      : Powered by: phpFK                                                                                                  |====================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] Use payload : /forum/thread.php?board=4&thema=349'"><svg/onload=prompt(/_indoushka_/);>{{7*7}}[+] http://127.0.0.1/forum/thread.php?board=4&thema=349%27%22%3E%3Csvg/onload=prompt(/_indoushka_/);%3E{{7*7}}Greetings to :=========================================================================================================================                                                                                                                                      |jericho * Larry W. Cashdollar * brutelogic* hyp3rlinx* 9aylas * shadow_00715 * LiquidWorm*                                            |                                                                                                                                              |=======================================================================================================================================

**File Tags**

*   ActiveX (932)
*   Advisory (81,379)
*   Arbitrary (16,086)
*   BBS (2,859)
*   Bypass (1,697)
*   CGI (1,024)
*   Code Execution (7,179)
*   Conference (678)
*   Cracker (841)
*   CSRF (3,321)
*   DoS (23,204)
*   Encryption (2,363)
*   Exploit (51,247)
*   File Inclusion (4,196)
*   File Upload (956)
*   Firewall (821)
*   Info Disclosure (2,722)
*   Intrusion Detection (885)
*   Java (3,003)
*   JavaScript (842)
*   Kernel (6,586)
*   Local (14,394)
*   Magazine (586)
*   Overflow (12,621)
*   Perl (1,423)
*   PHP (5,129)
*   Proof of Concept (2,335)
*   Protocol (3,567)
*   Python (1,510)
*   Remote (30,539)
*   Root (3,567)
*   Rootkit (506)
*   Ruby (609)
*   Scanner (1,633)
*   Security Tool (7,856)
*   Shell (3,165)
*   Shellcode (1,211)
*   Sniffer (893)
*   Spoof (2,189)
*   SQL Injection (16,237)
*   TCP (2,395)
*   Trojan (687)
*   UDP (884)
*   Virus (664)
*   Vulnerability (31,601)
*   Web (9,579)
*   Whitepaper (3,745)
*   x86 (961)
*   XSS (17,701)
*   Other

**File Archives**

*   June 2023
*   May 2023
*   April 2023
*   March 2023
*   February 2023
*   January 2023
*   December 2022
*   November 2022
*   October 2022
*   September 2022
*   August 2022
*   July 2022
*   Older

**Systems**

*   AIX (428)
*   Apple (1,980)
*   BSD (373)
*   CentOS (57)
*   Cisco (1,921)
*   Debian (6,762)
*   Fedora (1,691)
*   FreeBSD (1,244)
*   Gentoo (4,321)
*   HPUX (879)
*   iOS (345)
*   iPhone (108)
*   IRIX (220)
*   Juniper (67)
*   Linux (45,894)
*   Mac OS X (685)
*   Mandriva (3,105)
*   NetBSD (256)
*   OpenBSD (482)
*   RedHat (13,380)
*   Slackware (941)
*   Solaris (1,610)
*   SUSE (1,444)
*   Ubuntu (8,666)
*   UNIX (9,249)
*   UnixWare (186)
*   Windows (6,558)
*   Other

phpFK 8.0 Cross Site Scripting

The information leak threats are certainly new, but the education and messaging from security evangelists (and even just anyone trying to educate an older or less security-savvy family member) doesn’t change.

Thursday, June 15, 2023 14:06

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

Talos’ recent blog post on the dangers posed by the newly released “.zip” top-level domain (TLD) recently outlined how threat actors could create real URLs that look like file names and trick users into clicking on their links. .Zip and other TLDs that share characters with filename extensions also opens the door to accidental information leaks.

But these are far from the first TLDs to be problematic for users, especially those who are less educated about the verbiage that makes the internet work as intended.

The same day .zip was released as a TLD for anyone to register, the Internet Corporation for Assigned Names and Numbers (ICANN) also made .mov available as a TLD. The tricks here are obvious — think of someone who would see a file named “WeddingVideo.mov” and just assume it was from their legitimate family member.

(As a side note, I very much want to own jon.dad now, as .dad is also a TLD released in this batch.)

Attackers have long used tricky URLs to lure victims, though. We’ve written several times about how typo-squatted domains are used in cyber attacks. This is when an adversary takes a legitimate URL like twitter.com and uses a slightly modified version to make it just close enough that it looks like the real thing, like tvitter\[.\]com or twltter\[.\]com. And there are a variety of ways any slight DNS misconfiguration (which goes beyond just typing the URL into a browser window) could lead to information leaks or phishing lures.

The ever-present .com is also a common TLD that gets used to stand up legitimate-looking names for actors.

As security researcher and content creator Bobby Rauch pointed out in this recent post on Medium, attackers have used legitimate websites to mask malicious URLs to avoid detection and suspicion from the target.

For example, they can insert the “@” operator in a website URL to send someone to a different website, even though it may look legitimate.

The URL https://google\[.\]com@bing\[.\]com actually takes the user to bing.com even though it looks like it will send them to Google initially. Regardless of the TLD used there, an attacker could leverage it to trick someone who isn’t savvy enough to examine each detail of a URL.

There are other TLDs that could easily be used in convincing phishing emails or lure documents: .media is a long-available TLD that could easily be worked into a seemingly legitimate-looking file, and I’m assuming I wasn’t the only person to ever assume that the .run TLD could double as a file extension for a Mac driver.

There are certain dangers that .zip and .mov URLs pose to users, but we’ve always known that everyone needs to quadruple-check the URL they plan on visiting. The information leak threats are certainly new, but the education and messaging from security evangelists (and even just anyone trying to educate an older or less security-savvy family member) doesn’t change.

**The one big thing**

June’s Patch Tuesday is the first in a while in which Microsoft’s security updates didn’t include a warning against a zero-day vulnerability. Each of the previous four months included at least one issue that attackers were actively exploited in the wild. Still, Microsoft disclosed almost 70 vulnerabilities across its suite of software and hardware, including several that are “more likely” to be exploited. Cisco Talos specifically discovered two vulnerabilities in Microsoft Excel that the company patched Tuesday. These are important-severity remote code execution vulnerabilities that are triggered if the targeted user opens an attacker-created file.

**Why do I care?**

It’s certainly good news that there are no new zero-days included in this week’s Patch Tuesday — we’ve had enough of those already this year across all software manufacturers. But there are multiple vulnerabilities that are critical and have a very high severity score of 9.8 out of 10 that should be patched immediately.

**So now what?**

A complete list of all the vulnerabilities Microsoft disclosed this month is available on its update page. All Microsoft users should patch immediately or take appropriate mitigation steps as outlined in these advisories. Talos also released several Snort rules that can detect the exploitation of these vulnerabilities or block the attacker from taking malicious actions.

**Top security headlines of the week**

Progress Software released patches for several security vulnerabilities it discovered in its MOVEit file transfer software while researching a high-profile zero-day that has already led to multiple data breaches across the globe. The advisory for the new vulnerabilities states that they “could potentially be used by a bad actor to stage an exploit” but, currently, there is no evidence that they have been exploited in the wild. Security researchers have also published new proof of concept code to exploit CVE-2023-34362, the zero-day in MOVEit, which found that an attacker could exploit the issue to execute remote code on the targeted machine. It previously had only been identified as an SQL injection issue. Attackers have exploited CVE-2023-34362 to steal data from organizations using MOVEit, including the BBC, the Minnesota Department of Education and the Canadian province of Nova Scotia. (SecurityWeek, SC Media)

A group of high-profile American investors is reportedly considering purchasing assets belonging to NSO Group, the Israeli tech firm behind the infamous Pegasus spyware. The potential buyers include a financier who’s long been involved in Hollywood movies and a family member behind the Wrigley’s gum brand. Security experts and journalists have wondered about the financial status of NSO Group after it was added to the U.S. Department of Commerce’s list that bans the U.S. government and American companies from doing business with them. Meanwhile, the NSO Group has also reportedly been paying high-profile lobbying groups in D.C. to try and convince Congress to move the company from the banned list. The materials used by the lobbying groups reportedly state that the NSO Group’s software has a new “human rights governance compliance program.” (The Guardian, Haaretz)

America’s top cybersecurity official warned of the dangers of cyber attacks from Chinese state-sponsored actors, warning that critical infrastructure would become a key target in the event of a military conflict with China. Jen Easterly, speaking at an appearance at the Aspen Institute this week, said that China’s cyber espionage and offensive capabilities are an “epoch-defining threat.” Easterly, the director of the U.S. Cybersecurity and Infrastructure Security Agency (CISA), said Chinese threat actors were also likely to carry out cyber attacks against American infrastructure, like oil pipelines and electrical grids, should the two countries ever get into a kinetic military conflict. National security experts have long warned about a U.S.-China conflict if China ever invaded Taiwan. "Given the formidable nature of the threat from Chinese state actors, given the size of their capability, given how much resources and effort they're putting into it, it's going to be very, very difficult for us to prevent disruptions from happening," Easterly said. (CNBC, Reuters)

**Can’t get enough Talos?**

*   Talos Takes Ep. #142: Horabot is here to do "horable" things to your email inbox
*   The Need to Know: What does it mean when ransomware actors use “double extortion” tactics?
*   Vulnerability Spotlight: Two remote code execution vulnerabilities disclosed in Microsoft Excel
*   Threat Roundup for June 2 - 9
*   ThreatWise TV: Snort trends

**Upcoming events where you can find Talos**

**BlackHat** **(Aug. 5 - 10)**

Las Vegas, Nevada

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

  
**SHA 256:** a8a6d67140ac6cfec88b748b8057e958a825224fcc619ed95750acbd1d7a4848  
**MD5:** 8cb26e5b687cafb66e65e4fc71ec4d63  
**Typical Filename:** dattService.exe  
**Claimed Product:** Datto Service Monito  
**Detection Name:** W32.Auto:a8a6d6.in03.Talos

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

**SHA 256:** 7bf7550ae929d6fea87140ab70e6444250581c87a990e74c1cd7f0df5661575b  
**MD5:** f5e908f1fac5f98ec63e3ec355ef6279  
**Typical Filename:** IMG001.exe  
**Claimed Product:** N/A  
**Detection Name:** Win.Dropper.Coinminer::tpd

**SHA 256:** e4973db44081591e9bff5117946defbef6041397e56164f485cf8ec57b1d8934  
**MD5:** 93fefc3e88ffb78abb36365fa5cf857c  
**Typical Filename:** Wextract  
**Claimed Product:** Internet Explorer  
**Detection Name:** PUA.Win.Trojan.Generic::85.lp.ret.sbx.tg

Tag

#google