Saturday, December 28, 2024
HomeCyber security CourseDell, HP, & Lenovo System Found Using Outdated OpenSSL Cryptographic Library

Dell, HP, & Lenovo System Found Using Outdated OpenSSL Cryptographic Library

Published on

SIEM as a Service

The cybersecurity researchers at Binarly recently discovered that outdated versions of the OpenSSL cryptographic library are still being used by the following companies on their devices:- 

  • Dell
  • HP
  • Lenovo 

OpenSSL cryptographic library versions that are outdated provide a risk to the supply chain due to their outdated versions.

Core Issue

An open-source implementation of the UEFI is the EFI Development Kit, which is also known as EDK, which is an EFI as well. In this sense, the operating system functions as an interface between the firmware embedded within the hardware of the device and the operating system.

- Advertisement - SIEM as a Service

There is a cryptographic package built into the firmware development environment called CryptoPkg which, as a result, uses services from the OpenSSL project to provide cryptographic services within the firmware.

Several versions of OpenSSL have been found to be part of the firmware images associated with Lenovo Thinkpad enterprise devices, and here below we have mentioned all three versions of OpenSSL:- 

  • 0.9.8zb
  • 1.0.0a
  • 1.0.2j

There is one module in the firmware that relies on OpenSSL version 0.9.8zb which was released on August 4, 2014, known as InfineonTpmUpdateDxe. The Secure socket layer (SSL) and transport layer security (TLS) are open-source protocols that are implemented by OpenSSL.

On a regular basis, EDKII’s Github repository is updated and security issues are addressed by the developer community. A number of firmware images used by the above manufacturers were analyzed to determine if the issue was present in their devices.

Let’s have a look at how the different versions of OpenSSL related to the main enterprise vendors and how each version is linked to their release date for better understanding:-

OpenSSL Versions in Firmware

Oftentimes, firmware can be regarded as a single point of failure among all layers of a supply chain as well as the end-user devices at the end of the chain.

Recently, Microsoft highlighted the following key point:-

“There were at least 10 critical vulnerabilities identified in 32% of firmware images examined.”

Weakness Firmware images

While it is estimated that at least two or three vulnerabilities in firmware are present in about 20% of firmware updates.

In the summer of 2021, Lenovo enterprise devices were using the most recent version of the OpenSSL protocol which was available on the Internet at the time.

Many of Lenovo’s and Dell’s firmware packages still use an older version (0.9.8l), which was released on November 5, 2009, and is now over a decade old. 

Similarly, HP’s firmware code depended on a 10-year-old version of the library (0.9.8w), and not only that even the same was still used by many other manufacturers as well.

The binary code analysis field is one of the most complex in the world, and there is no easy solution. For supply chain security solutions based on SBOM to succeed in today’s world, the industry needs to change its mindset and begin to think about them differently.

Whenever it comes to the third-party code that is encapsulated in the code of the application, the list of dependencies is constantly failing. When dealing with SBOM failures, a ‘trust-but-verify’ approach is the best way to reduce supply chain risks and the likelihood of SBOM failures.

Gurubaran
Gurubaran
Gurubaran is a co-founder of Cyber Security News and GBHackers On Security. He has 10+ years of experience as a Security Consultant, Editor, and Analyst in cybersecurity, technology, and communications.

Latest articles

Lumma Stealer Attacking Users To Steal Login Credentials From Browsers

Researchers observed Lumma Stealer activity across multiple online samples, including PowerShell scripts and a...

New ‘OtterCookie’ Malware Attacking Software Developers Via Fake Job Offers

Palo Alto Networks reported the Contagious Interview campaign in November 2023, a financially motivated...

NjRat 2.3D Pro Edition Shared on GitHub: A Growing Cybersecurity Concern

The recent discovery of the NjRat 2.3D Professional Edition on GitHub has raised alarms...

Palo Alto Networks Vulnerability Puts Firewalls at Risk of DoS Attacks

A critical vulnerability, CVE-2024-3393, has been identified in the DNS Security feature of Palo...

API Security Webinar

72 Hours to Audit-Ready API Security

APIs present a unique challenge in this landscape, as risk assessment and mitigation are often hindered by incomplete API inventories and insufficient documentation.

Join Vivek Gopalan, VP of Products at Indusface, in this insightful webinar as he unveils a practical framework for discovering, assessing, and addressing open API vulnerabilities within just 72 hours.

Discussion points

API Discovery: Techniques to identify and map your public APIs comprehensively.
Vulnerability Scanning: Best practices for API vulnerability analysis and penetration testing.
Clean Reporting: Steps to generate a clean, audit-ready vulnerability report within 72 hours.

More like this

Fortinet Confirms Data Breach Following Hacker’s Claim of 440GB Data Theft

Fortinet, a leading cybersecurity firm, has confirmed a data breach involving a third-party cloud...

Amtrak Data Breach: Hackers Accessed User’s Email Address

Amtrak notified its customers regarding a significant security breach involving its Amtrak Guest Rewards...

SPECTR Malware Attacking Defense Forces of Ukraine With a batch script

The government computer emergency response team of Ukraine, CERT-UA, in direct cooperation with the...