New UEFI firmware flaws impact over 70 Lenovo laptop models

The UEFI firmware used in several laptops made by Lenovo is vulnerable to three buffer overflow vulnerabilities that could enable attackers to hijack the startup routine of Windows installations.

Lenovo has issued a security advisory disclosing three medium severity vulnerabilities tracked as CVE-2022-1890, CVE-2022-1891, and CVE-2022-1892.

The first is an issue in the ReadyBootDxe driver used in some Lenovo notebook products, while the last two are buffer overflow bugs in the SystemLoadDefaultDxe driver.

This second driver is used in the Yoga, IdeaPad, Flex, ThinkBook, V14, V15, V130, Slim, S145, S540, and S940 Lenovo lines, affecting over 70 individual models.

For more information on the impacted models, check out Lenovo’s product impact table at the bottom of the security advisory.

According to ESET, whose analysts discovered the three bugs and reported them to Lenovo, an attacker could leverage them to hijack the OS execution flow and disable security features.

“These vulnerabilities were caused by insufficient validation of DataSize parameter passed to the UEFI Runtime Services function GetVariable,” explains ESET Research in a tweet.

“An attacker could create a specially crafted NVRAM variable, causing buffer overflow of the Data buffer in the second GetVariable call.”

Variable to trigger exploitation of CVE-2022-1892
Variable to trigger exploitation of CVE-2022-1892 (ESET Research)

To help the cybersecurity community identify and fix similar issues, ESET submitted code improvements to Binarly’s UEFI firmware analyzer ‘efiXplorer,’ which is freely available on GitHub.

Hijacking the OS

UEFI firmware attacks are extremely dangerous because they enable threat actors to run malware early in an operating system’s boot process, even before Windows built-in security protections are activated.

This early level of access allows the malware to bypass or disable OS-level security protections, evade detection, and persist even after a disk is formatted.

While low-skilled remote actors can’t easily exploit these flaws, more capable hackers with access (malware or hands-on) to a targeted machine could leverage the vulnerabilities for silent yet ultra-powerful compromises.

To address the security risk, users of the affected devices are recommended to download the latest available driver version for their products which can be found on Lenovo’s official software download portal.

If you have trouble determining what model you’re using, Lenovo offers an automatic online detector that you can use instead.

Source :

Spectre and Meltdown Attacks Against OpenSSL

The OpenSSL Technical Committee (OTC) was recently made aware of several potential attacks against the OpenSSL libraries which might permit information leakage via the Spectre attack.1 Although there are currently no known exploits for the Spectre attacks identified, it is plausible that some of them might be exploitable.

Local side channel attacks, such as these, are outside the scope of our security policy, however the project generally does introduce mitigations when they are discovered. In this case, the OTC has decided that these attacks will not be mitigated by changes to the OpenSSL code base. The full reasoning behind this is given below.

The Spectre attack vector, while applicable everywhere, is most important for code running in enclaves because it bypasses the protections offered. Example enclaves include, but are not limited to:

The reasoning behind the OTC’s decision to not introduce mitigations for these attacks is multifold:

  • Such issues do not fall under the scope of our defined security policy. Even though we often apply mitigations for such issues we do not mandate that they are addressed.
  • Maintaining code with mitigations in place would be significantly more difficult. Most potentially vulnerable code is extremely non-obvious, even to experienced security programmers. It would thus be quite easy to introduce new attack vectors or fix existing ones unknowingly. The mitigations themselves obscure the code which increases the maintenance burden.
  • Automated verification and testing of the attacks is necessary but not sufficient. We do not have automated detection for this family of vulnerabilities and if we did, it is likely that variations would escape detection. This does not mean we won’t add automated checking for issues like this at some stage.
  • These problems are fundamentally a bug in the hardware. The software running on the hardware cannot be expected to mitigate all such attacks. Some of the in-CPU caches are completely opaque to software and cannot be easily flushed, making software mitigation quixotic. However, the OTC recognises that fixing hardware is difficult and in some cases impossible.
  • Some kernels and compilers can provide partial mitigation. Specifically, several common compilers have introduced code generation options addressing some of these classes of vulnerability:
    • GCC has the -mindirect-branch-mfunction-return and -mindirect-branch-register options
    • LLVM has the -mretpoline option
    • MSVC has the /Qspectre option

  1. Nicholas Mosier, Hanna Lachnitt, Hamed Nemati, and Caroline Trippel, “Axiomatic Hardware-Software Contracts for Security,” in Proceedings of the 49th ACM/IEEE International Symposium on Computer Architecture (ISCA), 2022.

Posted by OpenSSL Technical Committee May 13th, 2022 12:00 am

Source :

Altaro VM Backup’s Services Explained

Altaro VM Backup has a number of services, handing different types of operations and in certain cases it’s important to know the role of a specific service.

Below you can find an extensive list of each service’s responsibility.

Services on the Altaro VM Backup Console

The list below can also be used for services running on an Altaro Offsite Server machine only.

Display Name                          Description
Altaro VM Backup EngineManagement of backup schedules and configuration
Altaro VM Backup Deduplication ServicePerforms deduplication of data during backup operations
Altaro Offsite Server 6Altaro Offsite Server for v5 & v6 Offsite Copies
Altaro Offsite Server 8Altaro Offsite Server for Offsite Copies
Altaro Offsite Server 8 ControllerProvides an interface between the Offsite Server Management Console UI and the Altaro Offsite Server
Altaro VM Backup API ServiceEnables a RESTful API interface to Altaro VM Backup
Altaro VM Backup Hyper-V Host Agent – N1Facilitates backup and restore operations for Virtual machines on a Hyper-V Host and/or a VMware Host using VDDK 5.5
Altaro VM Backup Hyper-V Host Agent – N2Facilitates backup and restore operations for Virtual machines on a VMware Host using VDDK 6.5 & 6.7
Altaro VM Backup ControllerProvides an interface between the Management Console UI and the Altaro VM Backup Service

Services on a Hyper-V Host added to Altaro VM Backup

DisplayName                          Description
Altaro VM Backup Hyper-V Host Agent – N1Facilitates backup and restore operations for Virtual machines on a Hyper-V Host and/or a VMware Host using VDDK 5.5
Altaro VM Backup Hyper-V Host Agent – N2Facilitates backup and restore operations for Virtual machines on a VMware Host using VDDK 6.5 & 6.7
Altaro Offsite Server 6Altaro Offsite Server for v5 & v6 Offsite Copies
Altaro Offsite Server 8Altaro Offsite Server for Offsite Copies

Source :

Log4Shell Still Being Exploited to Hack VMWare Servers to Exfiltrate Sensitive Data

The U.S. Cybersecurity and Infrastructure Security Agency (CISA), along with the Coast Guard Cyber Command (CGCYBER), on Thursday released a joint advisory warning of continued attempts on the part of threat actors to exploit the Log4Shell flaw in VMware Horizon servers to breach target networks.

“Since December 2021, multiple threat actor groups have exploited Log4Shell on unpatched, public-facing VMware Horizon and [Unified Access Gateway] servers,” the agencies said. “As part of this exploitation, suspected APT actors implanted loader malware on compromised systems with embedded executables enabling remote command-and-control (C2).”

In one instance, the adversary is said to have been able to move laterally inside the victim network, obtain access to a disaster recovery network, and collect and exfiltrate sensitive law enforcement data.

Log4Shell, tracked as CVE-2021-44228 (CVSS score: 10.0), is a remote code execution vulnerability affecting the Apache Log4j logging library that’s used by a wide range of consumers and enterprise services, websites, applications, and other products.

Successful exploitation of the flaw could enable an attacker to send a specially-crafted command to an affected system, enabling the actors to execute malicious code and seize control of the target.

Based on information gathered as part of two incident response engagements, the agencies said that the attackers weaponized the exploit to drop rogue payloads, including PowerShell scripts and a remote access tool dubbed “hmsvc.exe” that’s equipped with capabilities to log keystrokes and deploy additional malware.

“The malware can function as a C2 tunneling proxy, allowing a remote operator to pivot to other systems and move further into a network,” the agencies noted, adding it also offers a “graphical user interface (GUI) access over a target Windows system’s desktop.”

The PowerShell scripts, observed in the production environment of a second organization, facilitated lateral movement, enabling the APT actors to implant loader malware containing executables that include the ability to remotely monitor a system’s desktop, gain reverse shell access, exfiltrate data, and upload and execute next-stage binaries.

Furthermore, the adversarial collective leveraged CVE-2022-22954, a remote code execution vulnerability in VMware Workspace ONE Access and Identity Manager that came to light in April 2022, to deliver the Dingo J-spy web shell.

Ongoing Log4Shell-related activity even after more than six months suggests that the flaw is of high interest to attackers, including state-sponsored advanced persistent threat (APT) actors, who have opportunistically targeted unpatched servers to gain an initial foothold for follow-on activity.

According to cybersecurity company ExtraHop, Log4j vulnerabilities have been subjected to relentless scanning attempts, with financial and healthcare sectors emerging as an outsized market for potential attacks.

“Log4j is here to stay, we will see attackers leveraging it again and again,” IBM-owned Randori said in an April 2022 report. “Log4j buried deep into layers and layers of shared third-party code, leading us to the conclusion that we’ll see instances of the Log4j vulnerability being exploited in services used by organizations that use a lot of open source.”

Source :

How to Enable a Pre-Boot BitLocker PIN on Windows

If you encrypt your Windows system drive with BitLocker, you can add a PIN for additional security. You’ll need to enter the PIN each time you turn on your PC, before Windows will even start. This is separate from a login PIN, which you enter after Windows boots up.

RELATED: How to Use a USB Key to Unlock a BitLocker-Encrypted PC

A pre-boot PIN prevents the encryption key from automatically being loaded into system memory during the boot process, which protects against direct memory access (DMA) attacks on systems with hardware vulnerable to them. Microsoft’s documentation explains this in more detail.

Step One: Enable BitLocker (If You Haven’t Already)

RELATED: How to Set Up BitLocker Encryption on Windows

This is a BitLocker feature, so you have to use BitLocker encryption to set a pre-boot PIN. This is only available on Professional and Enterprise editions of Windows. Before you can set a PIN, you have to enable BitLocker for your system drive.

Note that, if you go out of your way to enable BitLocker on a computer without a TPM, you’ll be prompted to create a startup password that’s used instead of the TPM. The below steps are only necessary when enabling BitLocker on computers with TPMs, which most modern computers have.

If you have a Home version of Windows, you won’t be able to use BitLocker. You may have the Device Encryption feature instead, but this works differently from BitLocker and doesn’t allow you to provide a startup key.

Step Two: Enable the Startup PIN in Group Policy Editor

Once you’ve enabled BitLocker, you’ll need to go out of your way to enable a PIN with it. This requires a Group Policy settings change. To open the Group Policy Editor, press Windows+R, type “gpedit.msc” into the Run dialog, and press Enter.

Head to Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives in the Group Policy window.

Double-click the “Require Additional Authentication at Startup” Option in the right pane.

Select “Enabled” at the top of the window here. Then, click the box under “Configure TPM Startup PIN” and select the “Require Startup PIN With TPM” option. Click “OK” to save your changes.

Step Three: Add a PIN to Your Drive

You can now use the manage-bde command to add the PIN to your BitLocker-encrypted drive.

To do this, launch a Command Prompt window as Administrator. On Windows 10 or 8, right-click the Start button and select “Command Prompt (Admin)”. On Windows 7, find the “Command Prompt” shortcut in the Start menu, right-click it, and select “Run as Administrator”

Run the following command. The below command works on your C: drive, so if you want to require a startup key for another drive, enter its drive letter instead of c: .

manage-bde -protectors -add c: -TPMAndPIN

You’ll be prompted to enter your PIN here. The next time you boot, you’ll be asked for this PIN.

To double-check whether the TPMAndPIN protector was added, you can run the following command:

manage-bde -status

(The “Numerical Password” key protector displayed here is your recovery key.)

How to Change Your BitLocker PIN

To change the PIN in the future, open a Command Prompt window as Administrator and run the following command:

manage-bde -changepin c:

You’ll need to type and confirm your new PIN before continuing.

How to Remove the PIN Requirement

If you change your mind and want to stop using the PIN later, you can undo this change.

First, you’ll need to head to the Group Policy window and change the option back to “Allow Startup PIN With TPM”. You can’t leave the option set to “Require Startup PIN With TPM” or Windows won’t allow you to remove the PIN.

Next, open a Command Prompt window as Administrator and run the following command:

manage-bde -protectors -add c: -TPM

This will replace the “TPMandPIN” requirement with a “TPM” requirement, deleting the PIN. Your BitLocker drive will automatically unlock via your computer’s TPM when you boot.

To check that this completed successfully, run the status command again:

manage-bde -status c:

If you forget the PIN, you’ll need to provide the BitLocker recovery code you should have saved somewhere safe when you enabled BitLocker for your system drive.

Source :

NIST Releases Updated Cybersecurity Guidance for Managing Supply Chain Risks

The National Institute of Standards and Technology (NIST) on Thursday released an updated cybersecurity guidance for managing risks in the supply chain, as it increasingly emerges as a lucrative attack vector.

“It encourages organizations to consider the vulnerabilities not only of a finished product they are considering using, but also of its components — which may have been developed elsewhere — and the journey those components took to reach their destination,” NIST said in a statement.

The new directive outlines major security controls and practices that entities should adopt to identify, assess, and respond to risks at different stages of the supply chain, including the possibility of malicious functionality, flaws in third-party software, insertion of counterfeit hardware, and poor manufacturing and development practices.

Software Supply Chain Risks

The development follows an Executive Order issued by the U.S. President on “Improving the Nation’s Cybersecurity (14028)” last May, requiring government agencies to take steps to “improve the security and integrity of the software supply chain, with a priority on addressing critical software.”

Supply Chain Risks

It also comes as cybersecurity risks in the supply chain have come to the forefront in recent years, in part compounded by a wave of attacks targeting widely-used software to breach dozens of downstream vendors all at once.

According to the European Union Agency for Cybersecurity’s (ENISA) Threat Landscape for Supply Chain Attacks, 62% of 24 attacks documented from January 2020 to early 2021 were found to “exploit the trust of customers in their supplier.”

“Managing the cybersecurity of the supply chain is a need that is here to stay,” said NIST’s Jon Boyens and one of the publication’s authors. “If your agency or organization hasn’t started on it, this is a comprehensive tool that can take you from crawl to walk to run, and it can help you do so immediately.”

Source :

Critical TLStorm 2.0 Bugs Affect Widely-Used Aruba and Avaya Network Switches

Cybersecurity researchers have detailed as many as five severe security flaws in the implementation of TLS protocol in several models of Aruba and Avaya network switches that could be abused to gain remote access to enterprise networks and steal valuable information.

The findings follow the March disclosure of TLStorm, a set of three critical flaws in APC Smart-UPS devices that could permit an attacker to take over control and, worse, physically damage the appliances.

IoT security firm Armis, which uncovered the shortcomings, noted that the design flaws can be traced back to a common source: a misuse of NanoSSL, a standards-based SSL developer suite from Mocana, a DigiCert subsidiary.

The new set of flaws, dubbed TLStorm 2.0, renders Aruba and Avaya network switches vulnerable to remote code execution vulnerabilities, enabling an adversary to commandeer the devices, move laterally across the network, and exfiltrate sensitive data.

Affected devices include Avaya ERS3500 Series, ERS3600 Series, ERS4900 Series, and ERS5900 Series as well as Aruba 5400R Series, 3810 Series, 2920 Series, 2930F Series, 2930M Series, 2530 Series, and 2540 Series.

Armis chalked up the flaws to an “edge case,” a failure to adhere to guidelines pertaining to the NanoSSL library that could result in remote code execution. The list of bugs is as follows –

  • CVE-2022-23676 (CVSS score: 9.1) – Two memory corruption vulnerabilities in the RADIUS client implementation of Aruba switches
  • CVE-2022-23677 (CVSS score: 9.0) – NanoSSL misuse on multiple interfaces in Aruba switches
  • CVE-2022-29860 (CVSS score: 9.8) – TLS reassembly heap overflow vulnerability in Avaya switches
  • CVE-2022-29861 (CVSS score: 9.8) – HTTP header parsing stack overflow vulnerability in Avaya switches
  • HTTP POST request handling heap overflow vulnerability in a discontinued Avaya product line (no CVE)

Even more concerningly, the vulnerabilities found in Avaya switches are zero-click, meaning they can be activated via unauthenticated network packets without any user interaction.

“These research findings are significant as they highlight that the network infrastructure itself is at risk and exploitable by attackers, meaning that network segmentation alone is no longer sufficient as a security measure,” Barak Hadad, head of research in engineering at Armis, said.

Organizations deploying impacted Avaya and Aruba devices are highly recommended to apply the patches to mitigate any potential exploit attempts.

Source :