Microsoft highlighted emerging confidential computing offerings for Azure during its Ignite conference.

Microsoft is putting hardware in charge of data protection in Azure to help customers feel confident about sharing data with authorized parties within the cloud environment. The company made a series of hardware security announcements at its Ignite 2022 conference this week to highlight Azure's confidential computing offerings.

Confidential computing involves creating a Trusted Execution Environment (TEE), essentially a black box to hold encrypted data. In a process called attestation, authorized parties can place code inside the box to decrypt and access the information without first having to move the data out of the protected space. The hardware-protected enclave creates a trustworthy environment in which data is tamper-proof, and the data isn't accessible to even those with physical access to the server, a hypervisor, or even an application.

"It's really kind of the ultimate in data protection," Mark Russinovich, Microsoft Azure's chief technology officer, said at Ignite.

**On Board With AMD's Epyc**

Several of Microsoft's new hardware security layers take advantage of on-chip features included in Epyc — the server processor from Advanced Micro Devices deployed on Azure.

One such feature is SEV-SNP, which encrypts AI data when in a CPU. Machine-learning applications move data continuously between a CPU, accelerators, memory, and storage. AMD's SEV-SNP ensures data security inside the CPU environment, while locking off access to that information as it goes through the execution cycle.

AMD's SEV-SNP feature closes a critical gap so data is secure at all layers while residing or moving in the hardware. Other chip makers have largely focused on encrypting data while in storage and in transit on communication networks, but AMD's features secure data while being processed in the CPU.

That offers multiple benefits, and companies will be able to mix proprietary data with third-party datasets residing in other secure enclaves on Azure. The SEV-SNP features use attestation to ensure incoming data is in its exact form from a relying party and can be trusted.

"This is enabling net new scenarios and confidential computing that was not possible before," said Amar Gowda, principal product manager at Microsoft Azure, during an Ignite webcast.

For example, banks will be able to share confidential data without the fear of anyone stealing it. The SEV-SNP feature will bring encrypted bank data into the secure third-party enclave where it could mingle with datasets from other sources.

"Because of this attestation and memory protection and integrity protection, you can rest assured that the data does not leave the boundaries in the wrong hands. The whole thing is about how do you enable new offerings on top of this platform," Gowda said.

**Hardware Security on Virtual Machines**

Microsoft also added additional security for cloud-native workloads, and the non-exportable encryption keys generated using SEV-SNP are a logical fit for enclaves where data is transient and not retained, James Sanders, principal analyst for cloud, infrastructure, and quantum at CCS Insight, says in a conversation with Dark Reading.

"For Azure Virtual Desktop, SEV-SNP adds an additional layer of security for virtual-desktop use cases, including bring-your-own-device workplaces, remote work, and graphics-intensive applications," Sanders says.

Some workloads haven't moved to the cloud because of regulation and compliance limitations tied to data privacy and security. The hardware security layers will allow companies to migrate such workloads without compromising their security posture, Run Cai, a principal program manager at Microsoft, said during the conference.

Microsoft also announced that the Azure virtual desktop with confidential VM was in public preview, which will be able to run Windows 11 attestation on confidential VMs.

"You can use secure remote access with Windows Hello and also secure access to Microsoft Office 365 applications within confidential VMs," Cai said.

Microsoft has been dabbling with the use of AMD's SEV-SNP in general-purpose VMs from earlier this year, which was a good start, CCS Insight's Sanders says.

Adoption of SEV-SNP is also important validation for AMD among data center and cloud customers, as previous efforts at confidential computing relied on partial secure enclaves rather than protecting the entire host system.

"This was not straightforward to configure, and Microsoft left it to partners to provide security solutions that leveraged in-silicon security features," Sanders says.

Microsoft's Russinovich said that Azure services to manage hardware and deployment of code for confidential computing are coming. Many of those managed services will be based on Confidential Consortium Framework, which is a Microsoft-developed open source environment for confidential computing.

"Managed service is in preview form ... we've got customers that are kicking the tires on it," Russinovich said.

Microsoft Secures Azure Enclaves With Hardware Guards

Confidential Containers (CoCo) is a new sandbox project of the Cloud Native Computing Foundation (CNCF) that enables cloud-native confidential computing by taking advantage of a variety of hardware platforms and technologies.

Confidential Containers (CoCo) is a new sandbox project of the Cloud Native Computing Foundation (CNCF) that enables cloud-native confidential computing by taking advantage of a variety of hardware platforms and technologies. The project brings together software and hardware companies including Alibaba-cloud, AMD, ARM, IBM, Intel, Microsoft, Red Hat, Rivos and others.  

The CoCo project builds on existing and emerging hardware security technologies such as Intel SGX, Intel TDX, AMD SEV and IBM Z Secure Execution, in combination with new software frameworks **to help better secure user data in use**. This will establish a new level of confidentiality, which does not rely on trust in the cloud providers and their employees, but on hardware-level cryptography. CoCo will support multiple environments including public clouds, on-premise and edge computing.

The goal of the CoCo project is to **standardize** confidential computing at the container level and **simplify** its consumption in Kubernetes. This is in order to enable Kubernetes users to deploy confidential container workloads using familiar workflows and tools without extensive knowledge of underlying confidential computing technologies.

The CoCo project aims to integrate Trusted Execution Environments (TEE) infrastructure with the cloud-native world. A TEE is at the heart of a confidential computing solution. TEEs are isolated environments with enhanced security, provided by confidential computing (CC) capable hardware that prevents unauthorized access or modification of applications and data while in use. You’ll also hear the terms "enclaves", "trusted enclaves" or "secure enclaves." In the context of confidential containers, these terms are used interchangeably.

**What does this actually mean?** 

Using CoCo, you will be able to deploy your workload on infrastructure owned by someone else, significantly reducing the risk of any unauthorized entity accessing your workload data and extracting your secrets. The infrastructure can be owned by a cloud provider, a different division in your organization such as the IT department or even an untrusted third party. This new level of confidentiality is achieved by, among other things, encrypting the computer’s memory and protecting other low level resources your workload requires at the hardware level. This includes the state of the CPU, physical memory, interrupts and more. Cryptography-based proofs help validate that no one has tampered with your workload, loaded software you did not want, read or modified the memory used by your workload, injected a malicious CPU state to attempt to derail your software or succeeded in doing anything out of order. In short, CoCo helps confirm that if either your software runs without being tampered with or it fails to run you will know about it.

For additional details see the CoCo project overview. 

In this blog we will focus on the first community release targeted for September 2022. The next sections provide more insight into what are the goals of this release and the supported use cases. We will also give a short overview of the architecture components supported in this release. 

Detailed release notes are available on the confidential containers GitHub repository.

**Goals of the first release**

This release focuses on the following:

*   **Simplicity** - Using a dedicated Kubernetes operator, the CoCo operator, for deployment and configuration. Our goal is to make this technology as accessible as possible hiding away most of the hardware-dependent parts 
    
*   **Stability** \- Supporting continuous integration (CI) for the key workflows of the release. We want to ensure that as the community grows and more contributors join, existing use cases remain stable.
    
*   **Documentation** - Detailed and clear instruction of how to deploy and use this release. Confidential computing is a vast and evolving field with many acronyms, building blocks and technology layers. We’d like to provide the users with enough information to understand and try out the use cases we describe.
    

Non-goals for the release include:

*   Full support and CI testing for all commonly used hardware architectures.
    
*   Performance and resource optimizations
    
*   Full integration with third-party services for attestation or key brokering
    
*   Full functionality and security features for all standard Kubernetes tools: some commands, notably those that access sensitive data in the workload, may either fail to function (being blocked for security reasons), or still route data through insecure channels.
    
*   Support for upstream versions of containerd and CRIO (this release relies on a customized version of containerd, which the operator installs for you)
    

We expect these limitations to be addressed in subsequent releases.

**Use cases supported in this release**

This release supports the following use cases:

*   Creating a sample CoCo workload
    
*   Creating a CoCo workload using a pre-existing encrypted image
    
*   Creating a CoCo workload using a pre-existing encrypted image on hardware with support for Confidential Computing (CC HW)
    
*   Building a new encrypted container image and deploying it as a CoCo workload
    

**Some insight into the CoCo architecture **

The following diagram provides a high level view of the main components the CoCo solution consists of and interact with: 

The CoCo solution embeds a Kubernetes pod inside a virtual machine (VM) together with an engine called the _**enclave software stack**_. There is a one-to-one mapping between a Kubernetes pod and a VM-based TEE (or enclave). The container images are kept inside the enclave and can be either signed or encrypted.

The **enclave software stack** is _**measured**_, which means that a  trusted cryptographic algorithm is used to authenticate its content. It contains the _**enclave agent**_ which is responsible for initiating attestation and fetching of the secrets from the key management service.

Supporting components for the solution are the _**container image registry**_ and the _**relying party**_, which combines the _**attestation service**_ and _**key management service**_.

The **container image registry** is responsible for storing and delivering encrypted container images. A container image typically contains multiple layers, and each layer is encrypted separately. At least one layer needs to be encrypted for the workload to be efficiently protected.

The **attestation service** is responsible for checking the measurement of the enclave software stack against a list of approved workloads, and authorize or deny the delivery of keys.

The **key management service** is responsible for storing secrets that the workload needs in order to run, such as disk decryption keys, and for delivering these secrets to the enclave agent.

After the VM has been launched, we can then summarize the flow CoCo follows in the following 4 steps (colored in red in the diagram above):

1.  The enclave agent sends a request to the attestation service. The attestation service responds with a cryptographic challenge for the agent to prove the workload’s identity using the measurement of the enclave. If the enclave agent responds to this challenge successfully, the attestation service notifies the key management service that secrets can be delivered.
    
2.  If the workload is authorized to run, the key management service finds the secrets corresponding to the workload, and sends them to the agent. Among the necessary secrets are the decryption keys for the disks being used.
    
3.  The image management service inside the enclave downloads container images from the container images registry, verifies them, and decrypts them locally to encrypted storage. At that point, the container images become usable by the enclave.
    
4.  The enclave software stack creates a pod and containers inside the virtual machine, and starts running the containers (all containers within the pod are secured).
    

**Why is Red Hat investing in this project? **

As part of the move to open hybrid cloud and in an effort to consolidate its relevant security aspects, advancement in technology allows our customers to further protect the data in use by providing an additional layer of encryption. There are certain industries that are highly sensitive and need additional protection for their workloads. As regulatory environments change, Red Hat intends to provide the necessary tools.

Red Hat believes that confidential computing can be a game changer for software manufacturers and cloud providers. It combines the advantages of cloud and on-premise while keeping the processes simple.

CoCo makes these new technologies easier to consume. Being able to transparently integrate confidential containers in Red Hat OpenShift, which is built on Kubernetes, is expected to become an important addition to the Red Hat product portfolio.

What is the Confidential Containers project? 

Hello everyone! Five years ago I wrote a blogpost about OpenSCAP. But it was only about the SCAP Workbench GUI application and how to use it to detect security misconfigurations. Alternative video link (for Russia): https://vk.com/video-149273431_456239104 This time, I will install the OpenSCAP command line tool on Ubuntu and use it to check for vulnerabilities […]

Hello everyone! Five years ago I wrote a blogpost about OpenSCAP. But it was only about the SCAP Workbench GUI application and how to use it to detect security misconfigurations.

Alternative video link (for Russia): https://vk.com/video-149273431\_456239104

This time, I will install the OpenSCAP command line tool on Ubuntu and use it to check for vulnerabilities on my local host.

**Installation**

First of all, we need to install OpenSCAP. I have Ubuntu 20.04.5 LTS on my host.

    $ lsb_release -a
    No LSB modules are available.
    Distributor ID:	Ubuntu
    Description:	Ubuntu 20.04.5 LTS
    Release:	20.04
    Codename:	focal

According to the official OpenSCAP website oscap tool can be installed on Ubuntu with the command apt-get install libopenscap8.

    $ sudo apt-get install libopenscap8
    [sudo] password for alexander: 
    Reading package lists... Done
    Building dependency tree       
    Reading state information... Done
    The following packages were automatically installed and are no longer required:
      libfwupdplugin1 python3-defusedxml python3-pyqt5.qtopengl python3-zmq
    Use 'sudo apt autoremove' to remove them.
    The following NEW packages will be installed:
      libopenscap8
    0 upgraded, 1 newly installed, 0 to remove and 31 not upgraded.
    Need to get 2,483 kB of archives.
    After this operation, 66.2 MB of additional disk space will be used.
    Get:1 http://ru.archive.ubuntu.com/ubuntu focal-updates/universe amd64 libopenscap8 amd64 1.2.16-2ubuntu3.2 [2,483 kB]
    Fetched 2,483 kB in 0s (5,700 kB/s)    
    Selecting previously unselected package libopenscap8.
    (Reading database ... 290720 files and directories currently installed.)
    Preparing to unpack .../libopenscap8_1.2.16-2ubuntu3.2_amd64.deb ...
    Unpacking libopenscap8 (1.2.16-2ubuntu3.2) ...
    Setting up libopenscap8 (1.2.16-2ubuntu3.2) ...
    Processing triggers for man-db (2.9.1-1) ...
    Processing triggers for libc-bin (2.31-0ubuntu9.9) ...

We can then check that the installation was successful with the command oscap -V

    $ oscap -V
    OpenSCAP command line tool (oscap) 1.2.16
    Copyright 2009--2017 Red Hat Inc., Durham, North Carolina.
    
    ==== Supported specifications ====
    XCCDF Version: 1.2
    OVAL Version: 5.11.1
    CPE Version: 2.3
    CVSS Version: 2.0
    CVE Version: 2.0
    Asset Identification Version: 1.1
    Asset Reporting Format Version: 1.1
    CVRF Version: 1.1
    ...

Everything looks good and now we need to get the content describing the vulnerability checks. It’s great that Canonical has invested in creating free OVAL content feeds that can be downloaded from https://ubuntu.com/security/oval.

We download the content with wget.

    $ wget https://security-metadata.canonical.com/oval/com.ubuntu.$(lsb_release -cs).usn.oval.xml.bz2
    --2022-10-01 14:00:00--  https://security-metadata.canonical.com/oval/com.ubuntu.focal.usn.oval.xml.bz2
    Resolving security-metadata.canonical.com (security-metadata.canonical.com)... 185.125.190.20, 185.125.190.29, 185.125.190.21, ...
    Connecting to security-metadata.canonical.com (security-metadata.canonical.com)|185.125.190.20|:443... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 276068 (270K) [application/x-bzip2]
    Saving to: ‘com.ubuntu.focal.usn.oval.xml.bz2’
    
    com.ubuntu.focal.usn.oval.xml.bz2               100%[=======================================================================================================>] 269.60K  1.35MB/s    in 0.2s    
    
    2022-10-01 14:00:00 (1.35 MB/s) - ‘com.ubuntu.focal.usn.oval.xml.bz2’ saved [276068/276068]

Unzip the data using bunzip2 tool:

    $ bunzip2 com.ubuntu.$(lsb_release -cs).usn.oval.xml.bz2
    $ ls com.ubuntu.*
    com.ubuntu.focal.usn.oval.xml

**Vulnerability report**

We can use the oscap tool to create an html vulnerability report. The tool shows the OVAL definition statuses while it is running.

    $ oscap oval eval --report report.html com.ubuntu.$(lsb_release -cs).usn.oval.xml
    Definition oval:com.ubuntu.focal:def:891000000: false
    Definition oval:com.ubuntu.focal:def:871000000: false
    Definition oval:com.ubuntu.focal:def:861000000: false
    Definition oval:com.ubuntu.focal:def:851000000: false
    Definition oval:com.ubuntu.focal:def:841000000: false
    ...
    Definition oval:com.ubuntu.focal:def:43322000000: false
    Definition oval:com.ubuntu.focal:def:43302000000: false
    Definition oval:com.ubuntu.focal:def:41716000000: false
    Definition oval:com.ubuntu.focal:def:100: true
    Evaluation done.

In this example, oscap has detected a vulnerability in the Firefox web browser.

And after updating the Firefox package on the host, this vulnerability disappears.

If you want to automatically process scan results, you can export them in XML format.

    $ oscap oval eval --results oval-results.xml com.ubuntu.$(lsb_release -cs).usn.oval.xml

**Separating Inventory and Vulnerability Detection: System Characteristics**

In most cases, using OpenSCAP looks like this. You install the OpenSCAP package on a target Linux host, copy the OVAL content to the host, and detect vulnerabilities directly on the host. You can then collect these results from the host and put them into some kind of vulnerability storage and prioritization solution.

Can we separate inventory collection from actual vulnerability detection? Yes, it is possible with the OVAL System Characteristics. The idea is that we collect inventory host data in a special XML format and then pass it as a parameter to the oscap tool. How does oscap know which objects to collect? It understands this from the same OVAL definition file.

So, we collect System Characteristics with

    $ oscap oval collect --syschar syschar.xml  com.ubuntu.$(lsb_release -cs).usn.oval.xml
    Collected: "oval:com.ubuntu.focal:obj:8910000001" : does not exist
    Collected: "oval:com.ubuntu.focal:obj:8910000000" : does not exist
    Collected: "oval:com.ubuntu.focal:obj:8710000001" : does not exist
    ...
    Collected: "oval:com.ubuntu.focal:obj:564910000000" : complete
    Collected: "oval:com.ubuntu.focal:obj:564810000010" : complete
    Collected: "oval:com.ubuntu.focal:obj:564810000000" : complete
    ...
    Collected: "oval:com.ubuntu.focal:obj:100" : complete

And then analyse and generate a report from it

    $ oscap oval analyse --results oval-results.xml com.ubuntu.$(lsb_release -cs).usn.oval.xml syschar.xml
    $ oscap oval generate report oval-results.xml > ssg-scan-oval-report.html

Therefore, it is theoretically possible to learn how to generate syschar.xml files without using the oscap utility and implement **fully agent-less remote scan**. But this is one for the future.

**System Characteristics Errors**

Unfortunately, there were bugs during testing of oscap 1.2.16. The System Characteristics syschar.xml has been created successfully. But attempts to analyze it with oscap led to errors:

    $ oscap oval analyse --results oval-results.xml com.ubuntu.$(lsb_release -cs).usn.oval.xml syschar.xml
    E: oscap:     Error occured when comparing a variable 'oval:com.ubuntu.focal:var:564810000000' value '0:5.4.0-126' with collected item entity = '0:5.15.0-1016'
    E: oscap:     Error occured when comparing a variable 'oval:com.ubuntu.focal:var:564710000000' value '0:5.4.0-126' with collected item entity = '0:5.4.0-1089'
    E: oscap:     Error occured when comparing a variable 'oval:com.ubuntu.focal:var:564410000000' value '0:5.4.0-126' with collected item entity = '0:5.15.0-1018'
    ...
    OpenSCAP Error: Invalid type of operation in string evaluation: 6. [../../../../src/OVAL/results/oval_cmp_basic.c:195]

At the same time, oval-results.xml was created and it was possible to generate an html report from it. But some of the checks are displayed in the error state.

I suspect that the problem is in the current version of oscap in the Ubuntu repository (1.2.16) and in the current actual version 1.3.6 it may work, but this needs to be checked. To do this, OpenSCAP should be installed from source.

Hi! My name is Alexander and I am a Vulnerability Management specialist. You can read more about me here. Currently, the best way to follow me is my Telegram channel @avleonovcom. I update it more often than this site. If you haven’t used Telegram yet, give it a try. It’s great. You can discuss my posts or ask questions at @avleonovchat.

А всех русскоязычных я приглашаю в ещё один телеграмм канал @avleonovrus, первым делом теперь пишу туда.

How to Perform a Free Ubuntu Vulnerability Scan with OpenSCAP and Canonical’s Official OVAL Content

The previously identified ransomware builder has veered in an entirely new direction, targeting consumers and business of all sizes by exploiting known CVEs through brute-forced and/or stolen SSH keys.

The powerful Chaos malware has evolved yet again, morphing into a new Go-based, multiplatform threat that bears no resemblance to its previous ransomware iteration. It's now targeting known security vulnerabilities to launch distributed denial-of-service (DDoS) attacks and perform cryptomining.

Researchers from Black Lotus Labs, the threat intelligence arm of Lumen Technologies, recently observed a version of Chaos written in Chinese, leveraging China-based infrastructure, and exhibiting behavior far different than the last activity seen by the ransomware-builder of the same name, they said in a blog post published Sept. 28.

Indeed, the distinctions between earlier variants of Chaos and the 100 distinct and recent Chaos clusters that researchers observed are so different that they say it poses a brand-new threat. In fact, researchers believe the latest variant is actually the evolution of the DDoS botnet Kaiji and perhaps "distinct from the Chaos ransomware builder" previously seen in the wild, they said.

Kaiji, discovered in 2020, originally targeted Linux-based AMD and i386 servers by leveraging SSH brute-forcing to infect new bots and then launch DDoS attacks. Chaos has evolved Kaiji's original capabilities to include modules for new architectures — including Windows — as well as adding new propagation modules through CVE exploitation and SSH key harvesting, the researchers said.

**Recent Chaos Activity**

In recent activity, Chaos successfully compromised a GitLab server and unfurled a flurry of DDoS attacks targeting the gaming, financial services and technology, and media and entertainment industries, along with DDoS-as-a-service providers and a cryptocurrency exchange.

Chaos is now targeting not only enterprise and large organizations but also "devices and systems that aren't routinely monitored as part of an enterprise security model, such as SOHO routers and FreeBSD OS," the researchers said.

And while the last time Chaos was spotted in the wild it was acting more as typical ransomware that entered networks with the purpose of encrypting files, the actors behind the latest variant have very different motives in mind, the researchers said.

Its cross-platform and device functionality as well as the stealth profile of the network infrastructure behind the latest Chaos activity appears to demonstrate that the aim of the campaign is to cultivate a network of infected devices to leverage for initial access, DDoS attacks, and cryptomining, according to the researchers.

**Key Differences, and One Similarity**

While previous samples of Chaos were written in .NET, the latest malware is written in Go, which is rapidly becoming a language of choice for threat actors due to its cross-platform flexibility, low antivirus detection rates, and difficulty to reverse-engineer, the researchers said.

And indeed, one of the reasons that the latest version of Chaos is so powerful is because it operates across multiple platforms, including not only Windows and Linux operating systems but also ARM, Intel (i386), MIPS, and PowerPC, they said.

It also propagates in a far different way than previous versions of the malware. While researchers were unable to ascertain its initial access vector, once it takes hold of a system, the latest Chaos variants exploit known vulnerabilities in a way that shows the ability to pivot quickly, the researchers noted.

"Among the samples we analyzed were reported CVEs for Huawei (CVE-2017-17215) and Zyxel (CVE-2022-30525) personal firewalls, both of which leveraged unauthenticated remote command line injection vulnerabilities," they observed in their post. "However, the CVE file appears trivial for the actor to update, and we assess it is highly likely the actor leverages other CVEs."

Chaos has indeed gone through numerous incarnations since it first emerged in June 2021 and this latest version is not likely to be its last, the researchers said. Its first iteration, Chaos Builder 1.0-3.0, purported to be a builder for a .NET version of the Ryuk ransomware, but the researchers soon noticed it bore little resemblance to Ryuk and was actually a wiper.

The malware evolved across several versions until version four of the Chaos builder that was released in late 2021 and got a boost when a threat group named Onyx created its own ransomware. This version quickly became the most common Chaos edition directly observed in the wild, encrypting some files but maintain overwritten and destroying most of the files in its path.

Earlier this year in May, the Chaos builder traded its wiper capabilities for encryption, surfacing with a rebranded binary dubbed Yashma that incorporated fully fledged ransomware capabilities.

While the most recent evolution of Chaos witnessed by Black Lotus Labs is far different, it does have one significant similarity with its predecessors — rapid growth that is unlikely to slow anytime soon, the researchers said.

The earliest certificate of the latest Chaos variant was generated on April 16; this is subsequently when researchers believe threat actors launched the new variant in the wild.

Since then, the number of Chaos self-signed certificates has shown "marked growth," more than doubling in May to 39 and then jumping to 93 for the month of August, the researchers said. As of Sept. 20, the current month has already surpassed the previous month's total with the generation of 94 Chaos certificates, they said.

**Mitigating Risk Across the Board**

Because Chaos is now attacking victims from the smallest home offices to the largest enterprises, researchers made specific recommendations for each type of target.

For those defending networks, they advised that network administrators stay on top of patch management for newly discovered vulnerabilities, as this is a principal way Chaos spreads.

"Use the IoCs outlined in this report to monitor for a Chaos infection, as well as connections to any suspicious infrastructure," the researchers recommended.

Consumers with small office and home office routers should follow best practices of regularly rebooting routers and installing security updates and patches, as well as leveraging properly configured and updated EDR solutions on hosts. These users also should regularly patch software by applying vendors' updates where applicable.

Remote workers — an attack surface that has significantly increased over the last two years of the pandemic — also are at risk, and should mitigate it by changing default passwords and disabling remote root access on machines that don't require it, the researchers recommended. Such workers also should store SSH keys securely and only on devices that require them.

For all businesses, Black Lotus Labs recommends considering the application of comprehensive secure access service edge (SASE) and DDoS mitigation protections to bolster their overall security postures and enable robust detection on network-based communications.

Chaos Malware Resurfaces With All-New DDoS & Cryptomining Modules

Hertz v0.3.0 ws discovered to contain a path traversal vulnerability via the normalizePath function.

Copy link

Contributor

** **ruokeqx** commented Sep 4, 2022 •**

**What type of PR is this?**

fix: A bug fix

**Check the PR title.**

*   This PR title match the format: (optional scope):
    
*   The description of this PR title is user-oriented and clear enough for others to understand.
    

**(Optional) Translate the PR title into Chinese.**

修复目录穿越漏洞

**(Optional) More detail description for this PR(en: English/zh: Chinese).**

en: fix by simply replace all backslashes with forward slashes  
zh(optional): 将反斜杠全部改成正斜杠

**Which issue(s) this PR fixes:**

Fixes #228

Currently hertz has no restriction on backslash in normalizePath function.

func normalizePath(dst, src \[\]byte) \[\]byte {
	dst \= dst\[:0\]
	dst \= addLeadingSlash(dst, src)
	dst \= decodeArgAppendNoPlus(dst, src)

	// remove duplicate slashes
	b := dst
	bSize := len(b)
	for {
		n := bytes.Index(b, bytestr.StrSlashSlash)
		if n < 0 {
			break
		}
		b \= b\[n:\]
		copy(b, b\[1:\])
		b \= b\[:len(b)\-1\]
		bSize\--
	}
	dst \= dst\[:bSize\]

	// remove /./ parts
	b \= dst
	for {
		n := bytes.Index(b, bytestr.StrSlashDotSlash)
		if n < 0 {
			break
		}
		nn := n + len(bytestr.StrSlashDotSlash) \- 1
		copy(b\[n:\], b\[nn:\])
		b \= b\[:len(b)\-nn+n\]
	}

	// remove /foo/../ parts
	for {
		n := bytes.Index(b, bytestr.StrSlashDotDotSlash)
		if n < 0 {
			break
		}
		nn := bytes.LastIndexByte(b\[:n\], '/')
		if nn < 0 {
			nn \= 0
		}
		n += len(bytestr.StrSlashDotDotSlash) \- 1
		copy(b\[nn:\], b\[n:\])
		b \= b\[:len(b)\-n+nn\]
	}

	// remove trailing /foo/..
	n := bytes.LastIndex(b, bytestr.StrSlashDotDot)
	if n \>= 0 && n+len(bytestr.StrSlashDotDot) \== len(b) {
		nn := bytes.LastIndexByte(b\[:n\], '/')
		if nn < 0 {
			return bytestr.StrSlash
		}
		b \= b\[:nn+1\]
	}

	return b
}

After:

func normalizePath(dst, src \[\]byte) \[\]byte {
	// replace all backslashes with forward slashes
	for {
		n := bytes.Index(src, bytestr.StrBackSlash)
		if n < 0 {
			break
		}
		src\[n\] \= '/'
	}
	...
}

**Codecov Report**

> Merging #229 (4ecd30e) into develop (8751608) will **decrease** coverage by 0.02%.  
> The diff coverage is 0.00%.

@@             Coverage Diff             @@
#\#           develop     #229      +/-   ##
===========================================
\- Coverage    59.19%   59.17%   -0.03%     
===========================================
  Files           79       79              
  Lines         8105     8110       +5     
===========================================
+ Hits          4798     4799       +1     
\- Misses        2953     2957       +4     
  Partials       354      354              

Impacted Files

Coverage Δ

pkg/protocol/uri.go

70.34% <0.00%> (-0.72%)

⬇️

pkg/network/standard/buffer.go

81.08% <0.00%> (-0.50%)

⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Copy link

Contributor Author

****ruokeqx** commented Sep 4, 2022**

Copy link

Contributor Author

****ruokeqx** commented Sep 4, 2022**

> When checking other http framework source code, I find that fasthttp community fix the same bug six months ago. Maybe we can borrow some code.
> 
> valyala/fasthttp#1226 valyala/fasthttp@6b5bc7b

They just repeat the logic, there is no need to write duplicate code.  
The point is that backslash also work in windows. So, essentially, we just need to replace the backslash with forward slash, by which we, to some extent, limit the separator.  
In my limited point of view, my fix is better.

@@ -480,6 +480,15 @@ func splitHostURI(host, uri \[\]byte) (\[\]byte, \[\]byte, \[\]byte) {

}

  

func normalizePath(dst, src \[\]byte) \[\]byte {

// replace all backslashes with forward slashes

for {

n := bytes.Index(src, bytestr.StrBackSlash)

**Choose a reason for hiding this comment**

The reason will be displayed to describe this comment to others. Learn more.

1.  Seems it will double check for bytes that have been replaced, is this an performance issue on long paths?
2.  I'm not sure it's a good idea to replace src in place, maybe it's hard to understand that if normalizePath has a return value and also modifies the input parameters.

**Choose a reason for hiding this comment**

The reason will be displayed to describe this comment to others. Learn more.

> 1.  Seems it will double check for bytes that have been replaced, is this an performance issue on long paths?
> 2.  I'm not sure it's a good idea to replace src in place, maybe it's hard to understand that if normalizePath has a return value and also modifies the input parameters.

maybe this one would be better

func normalizePath(dst, src \[\]byte) \[\]byte {
	dst \= dst\[:0\]
	dst \= addLeadingSlash(dst, src)
	dst \= decodeArgAppendNoPlus(dst, src)

	// replace all backslashes with forward slashes
	if filepath.Separator \== '\\\\' {
		for i := range dst {
			if dst\[i\] \== '\\\\' {
				dst\[i\] \= '/'
			}
		}
	}
	...
}

BTW: echo use function filepath.ToSlash

https://github.com/labstack/echo/blob/master/context\_fs.go#L33

func ToSlash(path string) string {
	if Separator \== '/' {
		return path
	}
	return strings.ReplaceAll(path, string(Separator), "/")
}

**Choose a reason for hiding this comment**

The reason will be displayed to describe this comment to others. Learn more.

bytes.IndexByte will do a SIMD accelerate in some platforms. Not sure which one is better.

And since the bug only happens in Windows? Maybe add a if filepath.Separator == '\\' { to filter the platform?

The example/standard demo seems still have the problem in Windows if the url is : 127.0.0.1:8888/..%5c..%5cgo.sum

Copy link

Contributor Author

****ruokeqx** commented Sep 5, 2022 •**

> The example/standard demo seems still have the problem in Windows if the url is : 127.0.0.1:8888/..%5c..%5cgo.sum

this version solve the problem

func normalizePath(dst, src \[\]byte) \[\]byte {
	dst \= dst\[:0\]
	dst \= addLeadingSlash(dst, src)
	dst \= decodeArgAppendNoPlus(dst, src)

	// replace all backslashes with forward slashes
	if filepath.Separator \== '\\\\' {
		for i := range dst {
			if dst\[i\] \== '\\\\' {
				dst\[i\] \= '/'
			}
		}
	}
	...
}

before the if judgment  
src = "/..%5c..%5cgo.sum"  
dst = "//..\\..\\go.sum"

curl -v 127.0.0.1:8888/..%5c..%5cgo.sum
\*   Trying 127.0.0.1:8888...
\* Connected to 127.0.0.1 (127.0.0.1) port 8888 (#0)
\> GET /..%5c..%5cgo.sum HTTP/1.1
\> Host: 127.0.0.1:8888
\> User-Agent: curl/7.83.1
\> Accept: \*/\*
\>
\* Mark bundle as not supporting multiuse
< HTTP/1.1 404 404 Page not found
< Date: Mon, 05 Sep 2022 09:10:07 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 26
<
Cannot open requested path\* Connection #0 to host 127.0.0.1 left intact

> > The example/standard demo seems still have the problem in Windows if the url is : 127.0.0.1:8888/..%5c..%5cgo.sum
> 
> this version solve the problem
> 
> func normalizePath(dst, src \[\]byte) \[\]byte {
> 	dst \= dst\[:0\]
> 	dst \= addLeadingSlash(dst, src)
> 	dst \= decodeArgAppendNoPlus(dst, src)
> 
> 	// replace all backslashes with forward slashes
> 	if filepath.Separator \== '\\\\' {
> 		for i := range dst {
> 			if dst\[i\] \== '\\\\' {
> 				dst\[i\] \= '/'
> 			}
> 		}
> 	}
> 	...
> }
> 
> before the if judgment src = "/..%5c..%5cgo.sum" dst = "//....\\go.sum"
> 
> curl -v 127.0.0.1:8888/..%5c..%5cgo.sum
> \*   Trying 127.0.0.1:8888...
> \* Connected to 127.0.0.1 (127.0.0.1) port 8888 (#0)
> \> GET /..%5c..%5cgo.sum HTTP/1.1
> \> Host: 127.0.0.1:8888
> \> User-Agent: curl/7.83.1
> \> Accept: \*/\*
> \>
> \* Mark bundle as not supporting multiuse
> < HTTP/1.1 404 404 Page not found
> < Date: Mon, 05 Sep 2022 09:10:07 GMT
> < Content-Type: text/plain; charset=utf-8
> < Content-Length: 26
> <
> Cannot open requested path\* Connection #0 to host 127.0.0.1 left intact

Good job! As for the performance part, maybe do a bench test to see the answer.

Copy link

Contributor Author

****ruokeqx** commented Sep 5, 2022**

> > > The example/standard demo seems still have the problem in Windows if the url is : 127.0.0.1:8888/..%5c..%5cgo.sum
> > 
> > this version solve the problem
> > 
> > func normalizePath(dst, src \[\]byte) \[\]byte {
> > 	dst \= dst\[:0\]
> > 	dst \= addLeadingSlash(dst, src)
> > 	dst \= decodeArgAppendNoPlus(dst, src)
> > 
> > 	// replace all backslashes with forward slashes
> > 	if filepath.Separator \== '\\\\' {
> > 		for i := range dst {
> > 			if dst\[i\] \== '\\\\' {
> > 				dst\[i\] \= '/'
> > 			}
> > 		}
> > 	}
> > 	...
> > }
> > 
> > before the if judgment src = "/..%5c..%5cgo.sum" dst = "//....\\go.sum"
> > 
> > curl -v 127.0.0.1:8888/..%5c..%5cgo.sum
> > \*   Trying 127.0.0.1:8888...
> > \* Connected to 127.0.0.1 (127.0.0.1) port 8888 (#0)
> > \> GET /..%5c..%5cgo.sum HTTP/1.1
> > \> Host: 127.0.0.1:8888
> > \> User-Agent: curl/7.83.1
> > \> Accept: \*/\*
> > \>
> > \* Mark bundle as not supporting multiuse
> > < HTTP/1.1 404 404 Page not found
> > < Date: Mon, 05 Sep 2022 09:10:07 GMT
> > < Content-Type: text/plain; charset=utf-8
> > < Content-Length: 26
> > <
> > Cannot open requested path\* Connection #0 to host 127.0.0.1 left intact
> 
> Good job! As for the performance part, maybe do a bench test to see the answer.

I did some simple benchmarks, when there are backslashes in path, for-range option is faster, when there is no backslash in path, IndexByte option is faster.

Choose IndexByte maybe more reasonable since most normal URLs don't have backslashes in them.

var benchDstBackslashShort \= \[\]byte("/..\\\\foo")
var benchDstBackslashLong \= \[\]byte("/..\\\\..\\\\..\\\\..\\\\..\\\\..\\\\..\\\\..\\\\..\\\\..\\\\foo")
var benchDstNoBackslashShort \= \[\]byte("/../foo")
var benchDstNoBackslashLong \= \[\]byte("/../../../../../../../../../../foo")

func BenchmarkForrange(b \*testing.B) {
	for i := 0; i < b.N; i++ {
		for i := range benchDstNoBackslashShort {
			if benchDstNoBackslashShort\[i\] \== '\\\\' {
				benchDstNoBackslashShort\[i\] \= '/'
			}
		}
		benchDstNoBackslashShort \= \[\]byte("/../foo")
	}
}

func BenchmarkIndexByte(b \*testing.B) {
	for i := 0; i < b.N; i++ {
		for {
			n := bytes.IndexByte(benchDstNoBackslashShort, '\\\\')
			if n < 0 {
				break
			}
			benchDstNoBackslashShort\[n\] \= '/'
		}
		benchDstNoBackslashShort \= \[\]byte("/../foo")
	}
}

environment

goos: windows
goarch: amd64
pkg: github.com/cloudwego/hertz/pkg/protocol
cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz

benchDstBackslashShort

BenchmarkForrange-12     	57650732	        19.92 ns/op	       8 B/op	       1 allocs/op
BenchmarkIndexByte-12    	43823608	        27.97 ns/op	       8 B/op	       1 allocs/op
PASS
ok  	github.com/cloudwego/hertz/pkg/protocol	2.521s

benchDstBackslashLong

BenchmarkForrange-12     	21818498	        52.70 ns/op	      48 B/op	       1 allocs/op
BenchmarkIndexByte-12    	 9185786	       130.1 ns/op	      48 B/op	       1 allocs/op
PASS
ok  	github.com/cloudwego/hertz/pkg/protocol	2.941s

benchDstNoBackslashShort

BenchmarkForrange-12     	53754288	        19.66 ns/op	       8 B/op	       1 allocs/op
BenchmarkIndexByte-12    	61503766	        19.34 ns/op	       8 B/op	       1 allocs/op
PASS
ok  	github.com/cloudwego/hertz/pkg/protocol	2.379s

benchDstNoBackslashLong

BenchmarkForrange-12     	21096711	        49.30 ns/op	      48 B/op	       1 allocs/op
BenchmarkIndexByte-12    	32403181	        37.07 ns/op	      48 B/op	       1 allocs/op
PASS
ok  	github.com/cloudwego/hertz/pkg/protocol	2.724s

PTAL. There may have a side effect which lead to a failure of existing UT

Copy link

Contributor Author

****ruokeqx** commented Sep 6, 2022 •**

My fault. Since we add if filepath.Separator == '\\' {, backslashes were replaced when running UT in my windows laptop. However, linux would not replace them.  
We can pass the the UT by modifying the code like below.

if filepath.Separator \== '\\\\' && string(parsedPath) != expectedPath {
    t.Fatalf("Unexpected Path: %q. Expected %q", parsedPath, expectedPath)
}

Also, github action can not check windows path.

CVE-2022-40082: fix: fix path-traversal bug by ruokeqx · Pull Request #229 · cloudwego/hertz

A stacked combination of hardware and software protects the next version of Windows against the latest generation of firmware threats.

Microsoft on Tuesday released a hefty PDF detailing Windows 11's new security-focused features, with a heavy emphasis on supporting zero trust.

For a couple of years now, Microsoft, Google, and Amazon have been working with the US federal government on improving cybersecurity through zero trust, among other techniques. It's no coincidence that these are the big three cloud service providers, of course; they are best positioned to institute controls to prevent catastrophic cyberattacks.

But Microsoft is also moving security way down the stack to where cloud rivals can't follow: firmware.

**Hardware Security Under Attack**

While network-level security is mandatory, it is not sufficient to protect against attackers who target firmware and other low-level elements of a computer.

Flaws in firmware for CPUs, printers, and other hardware can open a door to a corporate network. Malware like TrickBot, MoonBounce, and LoJax that worms its way into the silicon is difficult to dislodge.

"These new threats call for computing hardware that is secure down to the very core, including hardware chips and processors which store sensitive business information," Microsoft stated in the new report. "With hardware-based protection, we can enable strong mitigation against entire classes of vulnerabilities that are difficult to thwart with software alone." 

Besides the extra strength of the protection, Microsoft touts less slowdown using hardware-based protection versus running it in software.

The foundation of the built-in hardware security is a partnership between hardware root-of-trust and silicon-assisted security.

**Hardware Root-of-Trust**

Hardware root-of-trust is, by definition, "a starting point that is implicitly trusted." In the case of a PC, it's the part that checks BIOS code to ensure it's legitimate before it boots up. And anyone who's had to remove malware from a machine with infected BIOS knows how vital that is.

The new security measures include storing sensitive data such as cryptographic keys and user credentials isolated from the operating system within a separate secure area. Microsoft requires a Trusted Platform Module (TPM) 2.0 chip to be installed on both new and upgraded Windows 11 machines. The company had required TPM 2.0 capabilities on all new Windows 10 machines, but the latest version of Windows won't even run if the PC doesn't have a TPM 2.0 security chip.

"With hardware-based isolation security that begins at the chip, Windows 11 stores sensitive data behind additional barriers separated from the operating system," Microsoft wrote in its new report. "As a result, information including encryption keys and user credentials are protected from unauthorized access and tampering."

To provide TPM 2.0 protection directly on the motherboard, Windows 11 machines include the Microsoft Pluton security processor on the system-on-chip. While Pluton is not brand new – it was previewed back in November 2020 – integrating TPM 2.0 capabilities in this way eliminates one attack vector: the bus interface between the CPU and the TPM chip.

Not all Windows 11 machines will have a Pluton chip, but they will all have a TPM 2.0 chip.

**Silicon-Assisted Security**

The silicon-assisted security measures in Windows 11 start with a secure kernel carved out using virtualization-based security (VBS). 

"The isolated VBS environment protects processes, such as security solutions and credential managers, from other processes running in memory," Microsoft wrote. "Even if malware gains access to the main OS kernel, the hypervisor and virtualization hardware help prevent the malware from executing unauthorized code or accessing platform secrets in the VBS environment."

Hypervisor-protected code integrity (HCVI) uses VBS to check the validity of code within the secure VBS environment instead of in the main Windows kernel. Kernel mode code integrity (KMCI), as that's called, fends off attempts to modify drivers and the like. KMCI verifies that all kernel code is properly signed and has not been altered before it allows it to run. HVCI is supported in all versions of Windows 11 and enabled by default in most editions.

A further measure of protection against such attacks as memory corruption and zero-day exploits is offered by hardware-enforced stack protection. 

"Based on Controlflow Enforcement Technology (CET) from Intel and AMD Shadow Stacks, hardware-enforced stack protection is designed to protect against exploit techniques that try to hijack return addresses on the stack," Microsoft explained. The OS does this by creating a "shadow stack," set apart from other stacks, for return addresses.

To protect against physical incursions where an intruder surreptitiously installs malware from a device, Microsoft's line of Secured-core PCs will only run executables signed by "known and approved authorities," keeping external peripherals from accessing memory without authorization.

Even more firmware protection comes from Windows 11's universal implementation of the Unified Extensible Firmware Interface (UEFI) Secure Boot standard. The TPM stores a boot audit log, the Static Root of Trust for Measurement (SRTM), to check whether any attempts to subvert the boot were made.

UEFI is not unique to Windows machines, of course, but Windows 11 adds Dynamic Root of Trust for Measurement (DRTM) that checks the UEFI boot process for suspicious activity before allowing it to continue. Non-PC devices such as the Surface tablet use Firmware Attack Surface Reduction in place of DRTM.

Silicon-assisted security is part of the Pro, Pro Workstation, Enterprise, Pro Education, and Education versions of Windows 11. The Home editions will have some of these protections but not the full slate. See Microsoft's website for comparisons.

Microsoft Brings Zero Trust to Hardware in Windows 11

A Regular Expression Denial of Service (ReDoS) flaw was found in stealjs steal 2.2.4 via the input variable in main.js.

CVE-2022-37260: steal/main.js at c9dd1eb19ed3f97aeb93cf9dcea5d68ad5d0ced9 · stealjs/steal

Prototype pollution vulnerability in stealjs steal 2.2.4 via the optionName variable in main.js.

CVE-2022-37264: steal/main.js at c9dd1eb19ed3f97aeb93cf9dcea5d68ad5d0ced9 · stealjs/steal

A Regular Expression Denial of Service (ReDoS) flaw was found in stealjs steal 2.2.4 via the source and sourceWithComments variable in main.js.

CVE-2022-37262: steal/main.js at c9dd1eb19ed3f97aeb93cf9dcea5d68ad5d0ced9 · stealjs/steal

In Amanda 3.5.1, an information leak vulnerability was found in the calcsize SUID binary. An attacker can abuse this vulnerability to know if a directory exists or not anywhere in the fs. The binary will use `opendir()` as root directly without checking the path, letting the attacker provide an arbitrary path.

**What is Amanda?**

AMANDA, the Advanced Maryland Automatic Network Disk Archiver, is a backup solution that allows the IT administrator to set up a single master backup server to back up multiple hosts over network to tape drives/changers or disks or optical media. Amanda uses native utilities and formats (e.g. dump and/or GNU tar) and can back up a large number of servers and workstations running multiple versions of Linux or Unix. Amanda uses a native Windows client to back up Microsoft Windows desktops and servers.

The **latest stable version of Amanda**, 3.5.2 was released on 20th July 2022. As part of this release, we have addressed unintentional deletions of tape data in the backup environment. Your existing data on tapes will be safe and will not get replaced by your new backup set.

The most recent **stable release** is version 3.5.1, released on December 1, 2017.

The latest **release** is the 3.4.x series is 3.4,5, released on June 8, 2017. This is a bugfix release for 3.4.4.  

The latest **release** is the 3.3.x series is 3.3.9, released on February 10, 2016. It is a security fix. The amanda user was allowed to run any code as root, upgrade is not required if you trust the amanda user.

The latest **release** in the 3.2.x series is 3.2.3, released on May 9, 2011. It is a bug fix release for version 3.2.2.

The latest **release** in the 3.1.x series is 3.1.3, released on October 5, 2010. It is a security release for version 3.1.2.

Amanda-3.1.2 has a known security vulnerability, and all users should upgrade to Amanda-3.1.3 as soon as possible. See the security alert.

**Download here!** (README) | Learn more about Amanda's 3.5.2 release in our blog

**Release Notes for 3.5.2:**

The 3.5.2 version of Amanda will prevent unintentional deletions of data on tapes. With this release, you can stay assured that your data on tapes is safe, irrespective of the value set on the retention period.

**Enhancement**

Prevent auto-label from erasing tapes - Auto-label is disabled from claiming non-Amanda and other configuration labels by default. This change will prevent rewriting your existing tape media with new backup set.

**Release Notes for 3.5.1:**

*   compilation on Solaris
*   Do not check all 'r' bit on suid binary
*   Fix parsing of configuration override (-o)

*   can unset some setting

*   client code will not fail if shared memory is not available
*   amreport

*   lot of improvement

*   allow '\*' for a datestamp wildcard
*   amgetconf

*   print an empty string if a parameter is not set instead of 'no such parameter'

*   amdump

*   new --no-dump, --no-flush and --no-vault argument

*   amstatus fix
*   lock holding disk to protect multiple parallel access

**Release Notes for 3.5:**

*   Use different thread to connect to different client
*   amservice, amcheck, planner, dumper are no longer suid root
*   ambind

*   new suid program to bind to a privileged port

*   amanda-security.conf

*   new tcp\_port\_range, range of privileged tcp port
*   new udp\_port\_range, range of privileged udp port

*   S3 device

*   openstack keystone v3 support

*   device-property STORAGE-API must be set to SWIFT-3
*   new PROJECT-NAME device-property
*   new DOMAIN-NAME device-property

*   amfetchdump

*   rename --directory argument to --target

*   ampgsql

*   new --incremental property
*   new --remove-full-wal property
*   new --remove-incremental-wal property

  
*   fix planner looping
*   fix overflow in S3 device
*   fix compilation on OpenBSD
*   fix race in amarchive reader
*   fix amflush (flush date selected by user)
*   fix local auth, use getaddrinfo to find if the host is local
*   fix dumper cancelling the shm\_ring with a STRANGE result
*   fix chunker hang
*   Improve taperscan with chg-single and interactivity

**View more available versions**

**Amanda Web Pages**

*   Amanda wiki
*   **Backup & Recovery** (O'Reilly 2007) has a chapter dedicated to Amanda.

  
_Last updated: $Date: 2017-09-28 21:37:44 $_

Tag

#amd