This particular vulnerability was externally reported to Zyxel in April 2023 by an independent third party. The vulnerable service was software implementing IPSec and exploited over UDP port 500 using a “specially crafted” IKEv2 packet. Rapid7 reverse-engineered the patch and provided details. 

Digging Into The Supply Chain

I reviewed Rapid7’s analysis of the vulnerability as they went through the trouble of reverse engineering the patch. The vulnerability lies in the binary included in the Zyxel firmware called “sshipsecpm”. Many years ago I implemented a few different IPSec-based VPNs for organizations I worked for at the time. IPSec is a complex suite of protocols and something (in my opinion) you would not want to write your own implementation, but instead rely on a third party and perhaps license this functionality (or rely on an open-source implementation). In either case, the supply chain vulnerabilities in this library or service could trickle down and, if left unchecked, pose a threat to the entire system and all customers.

I looked up details on the “sshipsecpm” binary, essentially just Google searching for its name. While not many results were present, there are references to third parties that may be responsible for distributing this software. Some examples are listed below:

DFL-1660:/> about

D-Link Firewall 2.30.01.06-15906
Copyright Clavister 1996-2011. All rights reserved
QuickSec SSHIPSECPM version 2.1 library 2.1
Copyright 1997-2003 SafeNet Inc
Build: May 12 2011

Reference: https://forum.dlink.ru/viewtopic.php?f=3&t=150560

gateway:Clavister SG 51
ver: CorePlus 8.90.10.01-13428
QuickSec SSHIPSECPM version 2.1 library 2.1
Copyright 1997-2003 SafeNet Inc
Build : Feb 4 2010

Reference: https://vpn-help.shrew.narkive.com/jgswdHCx/tunnel-seems-to-be-up-but-cant-get-traffic-trough 

It appears as though the software is called “Quicksec SSHIPSECPM” and is likely included with both D-Link (a name you likely recognize) and Clavister firewalls (a name you may not recognize as Clavister is a Swedish vendor who sells firewalls and other security appliances). A quick search on “Safenet” shows that this company was sold a couple of times and is now owned by Thales. It is difficult to determine exactly where the software came from, but evidence points to Zyxel deciding not to implement its own IPSec stack.

Potential Impact

While the vulnerability in question was disclosed by Zyxel and the patches provided, the story goes a bit deeper and points to a supply chain issue. This particular IPSec software, and its associated vulnerability, seems to be present in other products although the threat could have been mitigated in other implementations. 

Generally, there is less attention paid to third-party software products, especially for IT infrastructure devices such as firewalls. We tend to trust our vendors to develop products securely. But as this example of the Zyxel firewall shows, attackers do pay attention and take advantage of the complexities of our IT infrastructure supply chain.

Eclypsium provides organizations with supply chain intelligence so that they can assess the risk of IT products—even before bringing them on board. We’ve already done the deep analysis of hardware, firmware, and software components so that you can evaluate risk before purchase, or understand what risk you have present in your environment. In addition, our supply chain security platform helps you to continuously monitor and remediate these threats in your production assets, including for network devices such as firewalls, ADCs, and VPNs. 

Further Reading

• White paper: Network Infrastructure on the Front Line
• Blog: A New Approach to Defending Network Infrastructure from Ransomware Groups and APTs
• Product tour: Eclypsium Guide to Supply Chain Security

The post Zyxel Firewall Vulnerabilities Reveal the Complexity of the IT Infrastructure Supply Chain appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

The U.S. National Security Agency (NSA) recently published a cybersecurity information sheet (CSI) that provides a deeper dive into the Device pillar. This is timely guidance because the device level is where attackers are increasingly active yet also where Zero Trust programs are typically the weakest. This is because most organizations lack deep technical insight into their actual devices. Most endpoint security products work at the application/OS level yet lack insight into the supply chain elements such as hardware, physical components, firmware, boot processes, and the other low-level systems and configurations that govern how an asset actually does its job. And of course, many devices such as network and IoT devices can’t support an endpoint agent at all. 

With this in mind, let’s briefly take a look at some of the lessons from the recent NSA doc titled, Advancing Zero Trust Maturity Throughout the Device Pillar.

Trust Below the OS

First and foremost, the NSA doc defines what the device pillar entails, specifically calling out the critical components and code that sit below the operating system.

This ZT device pillar CSI prescribes mechanisms to shield devices from low-level, persistent threats over their entire lifecycle. Adoption of a ZT mindset enables organizations to never assume devices within an established environment are secure or that actors cannot hide from defenses in the OS or applications by delving into hardware and firmware. 

This focus on hardware and firmware is consistent across the entire document. Threat examples focus on firmware implants, malicious bootloaders, and exploits against device components. Vulnerability and device management calls out firmware, server BMC configurations, TPM certificates, and similar low-level resources below the operating system. This is important because these are precisely the areas where many organizations place the most blind trust. 

Device Inventory and the Supply Chain

The NSA doc says that Zero Trust for devices needs to go beyond just listing out the assets in inventory. Organizations need to dig deeper to audit the low-level components within those devices and across the complete technology lifecycle. This specifically calls out the need for processes and tools to proactively verify the integrity of the supply chain. The document calls out the following phases of maintaining a device inventory.  

• Procurement: Identify criteria governing device purchases…may involve the need for specific Trusted Platform Module (TPM) certificates, firmware configuration, or component part revisions. Vendors may list multiple variants or configurations of the same device, but only some may have the necessary components and capabilities.
  
• Acceptance Testing: NIST SP 800-161 calls for enterprises to adopt acceptance testing as a mechanism to audit supply chain integrity. Software Bill of Materials (SBOM), Reference Integrity Manifest (RIM), and TPM Platform Certificate provide artifacts that establish an auditable chain of custody from the production factory to the receiving organization.
  
• Deprovisioning: Devices may store protected data within components other than the storage drive. Plan to securely erase storage media, factory reset firmware, securely erase TPM NVRAM memory, reset Baseboard Management Controller (BMC) configurations, remove UEFI Secure Boot modifications, and clean up other organization-specific customizations before retiring a device. Inventory should support status records necessary to ensure safe and secure deprovisioning.

This guidance reveals how device-level security and supply chain security are intertwined. An organization simply can’t understand the security of its assets if they don’t know precisely what should be inside those assets, what actually is inside them, and where they come from.

Controlling Access Based on Measured Risk

A core tenet of Zero Trust is that access should never be granted by default, but based on active evaluation of an asset’s risk. In the context of the device pillar, this means that organizations must have the prerequisite ability to determine device-level risk in the first place. This could be ensuring that all critical code is properly updated or that the integrity of that code has not been altered. Naturally, risk will also need to incorporate any signs of known threats or abnormal behavior. Furthermore, Zero Trust recognizes that security is not a static state and that a device that was verified in the past can’t be blindly trusted in the present. This means that assessing the risk of a device can’t be a one-time event, but must be a continuous process that can identify new risks as they develop.

Ultimately, organizations will need to put this risk context into action. Security teams will need to establish the criteria for what should and should not be allowed on an organization’s network. It could be an overall risk score for a device or based on the presence of a critical hardware or firmware vulnerability. The appropriate policies and responses will naturally vary based on the risk tolerance of each enterprise or agency. 

Automated Vulnerability and Patch Management

Most every organization spends considerable effort scanning for vulnerabilities and applying patches. However, the CSI calls out the importance of the system and component vulnerabilities that vulnerability management teams often miss. The document calls out the following: 

Organizations must maintain awareness of firmware patches below the software layer. These patches may not be delivered via OS patch managers or other automated patching solutions. Some patches may come from the system vendor, while others may be specific to an individual component manufacturer (e.g., SSD firmware provided by the storage vendor – not the system vendor). There are two general realms of device-specific patches:

1. Fixed System firmware: System vendors collaborate with soldered component vendors to deliver patches to customers. CPU microcode and NIC (network interface card) firmware is usually shared by the device’s manufacturer.

2. Component firmware: Most frequently applies to components with standardized connectors such as storage drives or graphics processors. Individual component vendors provide firmware updates for their specific products.

This highlights multiple important points. First, the complex nature of technology supply chains can make it hard to know exactly where important firmware updates will come from, if at all. For example, from one laptop vendor or model to another, an update may be handled by the OS, be delivered as firmware updates from the OEM, from the chipset vendor, or may need to be downloaded and applied individually by the customer. This makes it very easy for organizations to overlook critical updates unless they have a consistent way of auditing the supply chain security and posture across all their vendors and models. 

Secondly, these same issues extend down to the individual hardware and software components within a system. In addition to keeping the system BIOS or UEFI firmware up to date, teams must be able to find and address weaknesses in a device’s SSD, network controller, PCIe controller, or dozens of other components. This is again an area that will almost certainly be missed by traditional scans and will need to be handled by a supply chain security platform.

Threat Detection and Response

With all this focus on securing the device layer, it is important to remember why it has become such a priority. In short, attackers have recognized the device layer as the weak link in many organizations. Adversaries have targeted network devices as initial access vectors that can then be used to spread within an organization. On laptops and servers, low-level implants and backdoors can be used to maintain long-term persistence while evading more traditional protections. The device pillar CSI calls out the following:

In addition to the more common high-level threats to operating systems and application software, ZT capabilities must defend systems from persistent and hard-to-detect threats against devices. Past examples of low-level, persistent threats include:

• LoJax boot rootkit 
• MosaicRegressor firmware implant
• UEFI Secure Boot bypasses BootHole and BlackLotus
• Side channel vulnerabilities such as Spectre, Meltdown, Fallout, ZombieLoad, NetSpectre, Downfall, and Inception
• SSD over-provisioning malware

This is yet another area where organizations can have gaps. Most security teams lack any visibility into threats on non-traditional devices such as network devices, security appliances, or server BMCs. And while traditional EDR/XDR tools can look for threats, they often rely on the host operating system for information. A threat residing below the OS can easily provide false information up to the OS or disable protections entirely. Yet another area where firmware and supply chain security tools can close a critical gap.

These are some of the key ways that Zero Trust intentions turn into Zero Trust practices at the device level. And as the NSA doc calls out, the device pillar of Zero Trust requires organizations to dig deeper into their devices than they may have in the past. The good news is that new security tools are available that can make this a simple, highly automated process. That is our mission at Eclypsium, and if you would like to learn more, please contact the team at info@eclypsium.com.

For further reading please check out the following assets:

• Eclypsium Zero Trust for Endpoints solution
• Zero Trust for Devices solution brief

The post NSA Guidance Calls Out What Your Zero Trust Strategy is Probably Missing appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

The Universe of Digital Supply Chain

Imagine you are offered a drink. You don’t know what it is or what’s in it. It’s unlikely you’d drink it unless you trust the person giving it to you or some third-party attesting that its contents are safe to drink, perhaps through some certification label with ingredients listed. Yet this type of blind trust is exactly what we do when it comes to the external technology, both hardware and software, we use in our organizations.

Every modern organization depends on products from hundreds of vendors and suppliers. In the age of global interconnected digital supply chains, every product is built using components from many other suppliers, from software and hardware vendors to open-source developer communities.

Software supply chain security or more generally digital supply chain security is an important topic of conversations. Software is everywhere—from every application, to every device and its components. Fundamentally, we can view the entire digital supply chain security space as having two distinct and complementary parts: application software supply chain security and infrastructure supply chain security.

The application software supply chain security part helps software developers and vendors protect their software development environment and applications they build which typically includes source code analysis, analysis of third-party and open-source dependencies, and securing the CI/CD and delivery pipelines. For an overview of solutions focusing on the developer side of software supply chain security, I recommend reading Software Supply Chain Vendor Landscape research.

In this post I will focus on the other part of the digital supply chain security landscape: Infrastructure Supply Chain Security, or solutions which help organizations secure the supply chain of external products they use in their IT infrastructure.

Enterprise IT infrastructure combines multiple types of products such as user devices (endpoints), servers in corporate IT and data centers, network devices in network infrastructure, the software and hardware stack powering cloud infrastructure, and other types of infrastructure which are rapidly developing like enterprise IoT.

Infrastructure is what runs critical applications and workloads and is therefore fundamental to their security. If the infrastructure is vulnerable or compromised, all applications and workloads handling sensitive data are impacted.

Let me start with a simple example.

A typical PC is built by 65 direct suppliers, with another 200 upstream suppliers based in 39 countries who build the components and develop the underlying code. A popular HP Pavilion 550 desktop has over 4,500 models with various configurations of components and versions of motherboards. Each Pavilion 550 has multiple components from CPU to graphics cards to network adapters to storage devices to management chips—each of these components runs their own software or firmware code, from Linux-based OSes to equally complex firmware architectures like UEFI to proprietary code developed by suppliers of these components or their third-party suppliers. 

The Modern “Cybersecurity” Problem Is a Supply Chain Security Problem

Do we want to trust all of our vendors and all of their suppliers? Are we confident that each one of them will build secure software and hardware according to the security practices our organizations require? Have any of our suppliers been compromised by threat actors? These components could be altered or have backdoors, introduced by suppliers or external threat actors. All of these components have security vulnerabilities which are going to be used to compromise organizations using these products.

This is just one example: a PC such as the one you might be using to read this article. The problem grows exponentially larger when you consider other parts of your IT infrastructure, such as servers running critical workloads, network devices, and software technologies powering cloud infrastructure. Every time we blindly trust these products and components from the outside, we are accepting a substantial amount of risk.

A server may have anywhere between 50 and 100 of these components. A network device from Cisco, F5 Networks, HPE Aruba, or other vendors are similarly complex systems running their own network OS. Components like the Apache Log4J software library are used by both software applications and network devices, and thus were impacted by the Log4Shell vulnerability. As I write this, organizations across the globe are being targeted via the CitrixBleed vulnerability in Citrix NetScaler devices.

We don’t have easy ways to check the millions of lines of code and the risks of the technology that we consume. We have to stamp out this blind trust with new tools that can assess digital technology products by understanding their ingredients, how they’re configured, and if they have been altered in any way.

Gartner currently estimates $215 billion will be spent on cybersecurity in 2024, up 14% from 2023, but few of us have confidence that this will meaningfully affect outcomes. That’s because current cybersecurity controls don’t understand this complexity of modern digital supply chains and are thus incapable of addressing the root problem of digital supply chain security. Endpoint security tools are hopefully good at what they do—discovering malware on user endpoints. They have not been designed to deal with the risks of underlying components and ingredients within hardware and software products.

The network scanning tools we use to discover vulnerable network assets similarly have not been designed to understand these devices and software they run “from within,” with visibility into the ingredients devices are made of. They perform surface scans and can’t see deep enough within these assets to understand if they’ve been compromised, and often overwhelm security teams with “critical findings.”

Supply Chain Attacks Are Soaring

If we dive into root causes of most breaches today, we see that incidents involving vulnerabilities in software or hardware products are soaring. Akamai reported that ransomware groups are shifting tactics from phishing and stolen credentials to exploiting vulnerabilities, and said that this shift drove a 143% increase in ransomware victims from Q1 2022 and Q1 2023. Palo Alto Networks Unit 42 has found 48% of ransomware attacks start by exploiting software vulnerabilities.  

In 2023 alone, ransomware groups like LockBit, ALPHV, BlackCat, and FIN8, compromised many organizations by targeting vulnerable hardware devices and essential IT software like VMWare ESXi. Hotel and entertainment giant MGM spent $110 million cleaning up after the ALPHV ransomware group compromised its ESXi infrastructure. The Russia-linked LockBit recently added Boeing to the 1,800 victims it has claimed since 2019, claiming to have hacked the aerospace giant by exploiting a zero-day vulnerability. LockBit is known to target IT infrastructure such as F5 Networks and Fortinet appliances and ESXi infrastructure.

Security incidents with wide impact in 2023 have highlighted serious weaknesses in the digital supply chain, such as: vulnerabilities in MOVEit by Progress Software; firmware backdoor capabilities in Gigabyte systems; vulnerabilities in remote management components used by most major server manufacturers; hardware vulnerabilities like Downfall, Zenbleed, and other vulnerabilities in CPU components.

Additionally, ransomware groups also breached major infrastructure vendors including TSMC, MSI, Western Digital, exposing sensitive information about their products, such as signing keys and source code, that could be used by attackers to develop further supply chain attacks.

While ransomware groups threaten serious financial pain for the private sector, state-sponsored threat actors target national infrastructure. BlackLotus, Volt Typhoon, and BlackTech threat actors took aim at the supply chain of PCs, servers, and network devices by multiple manufacturers as initial access vector and to establish persistence. 

Geopolitical risks continue to drive concerns of dependency on critical technology developed by foreign manufacturers like Huawei and ZTE. Recently, disk drive components used in U.S. government agencies were found to be manufactured by a company with ties to the PRC’s PLA.

The security of the digital supply chain has taken center stage in U.S. national strategy. Two of the five pillars of the U.S. National Cybersecurity Strategy released in March 2023 are designed to strengthen the transparency and security of software and infrastructure supply chains. Following Executive Order 14028: Improving the Nation’s Cybersecurity, federal authorities including DHS, CISA, NIST, and the NTIA have been driving regulations and guidelines aimed at improving supply chain security.

Introducing the Eclypsium Guide to Supply Chain Security

It can all seem overwhelming. How can we, as an industry, stop placing blind trust in the digital supply chain and start managing the risk, both in applications and infrastructure? How are organizations supposed to demystify complex supply chains that are constantly changing with hundreds of suppliers and sub-suppliers, across dozens of technology vendors? 

The first step in this journey starts with supply chain intelligence. Returning to our drink analogy, most of us don’t have a portable kit to test the ingredients in the drink offered. But we would be more likely to accept a drink if we had third-party attestation to the ingredients included, nutritional facts, and any possible risk. Until now, there were no tools available to verify the ingredients in the digital products we use and assess their risk to our infrastructure. 

Today we are launching “the standard repository for all knowledge and wisdom” in digital supply chain security. Eclypsium created the Guide to help you begin to navigate the depths of this universe of external digital products and components. We want to arm our customers’ IT and security teams with intelligence and tools to verify the risk and integrity of every hardware, software, and cloud product they use in their infrastructure. 

Take a Tour of the Guide

We believe that organizations no longer need to blindly trust hardware and software from their suppliers or treat them as black boxes. Every organization should be able to see and verify what technology is made of before it’s used and after it is deployed. Every organization should be able to understand and control the risk that technologies bring throughout their lifecycle. We believe that securing the Infrastructure Supply Chain is the foundation of every organization’s security. Everything else is built on top of it. 

This will change how we manage cyber risk from our suppliers of technology. Assumptions and blind trust will be replaced by verification. At Eclypsium, we are committed to making this a reality together with our customers and partners.

We are starting an early access program for the Guide. If you are interested in getting access and helping us improve it, please let us know.

Don’t Panic!

The post Don’t Panic: Trust Your Tech with Supply Chain Intelligence appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

Low-level threats have allowed attackers to burrow beneath the OS and its traditional protections at scale, ensuring their malicious code runs first and runs at the most fundamental levels that the OS and all applications depend on. It fundamentally changes the when and where the battle takes place on a given device. 

Supply chain threats likewise change the when and where of cyberattacks, but on an even more profound level. Instead of attacking an enterprise directly, supply chain attacks shift the fight to the vendors, suppliers, and software repositories that underpin all enterprise technology. This can include software, firmware, and hardware. Thus, in many if not most cases, firmware attacks can be seen as a subset of supply chain attacks. They end up being very interrelated ideas. Firmware attacks go to the root of how technology works, and supply chain attacks go to the root of where technology comes from.

Drawing Inspiration from MITRE ATT&CK

Cybersecurity leaders and professionals have limited time and resources, so it is important that their efforts and decisions are informed by the tactics and techniques that attackers use in the real world. The MITRE ATT&CK framework has proven to be one of the most powerful industry tools in this regard. The framework identifies more than 200 attacker techniques that are categorized under 14 different high-level tactics. The tactics can largely be thought of as phases of an attack beginning with reconnaissance, progressing through various phases of an intrusion, and culminating in a theft or destructive impact.  

Given the sudden popularity of supply chain and firmware threats, it makes sense to take a deeper look at these areas in the context of ATT&CK. Of course, ATT&CK does cover some of the basics of threats in these areas. But at the same time, it’s important to appreciate how broadly these areas apply to the lifecycle of attack. Many of the same issues that are often applied to operating systems and applications can apply to hardware and firmware. They will have their own vulnerabilities, provide their own infection vectors, and allow for some of the most powerful forms of persistence and defense evasion.

With that in mind, let’s take a deeper look at some of the ATT&CK tactics in the context of supply chain and firmware threats. While we don’t go into the details of every technique, we have compiled the following table to highlight some of the most important techniques within eight ATT&CK tactics.

Reconnaissance

Reconnaissance involves a variety of active and passive adversary techniques to identify target assets and vulnerabilities. Almost any reconnaissance effort that can be applied to software will likewise apply to firmware, and the same techniques applied to enterprises can be applied to the supply chain. This can include: 

• Actively scanning for flaws within software and firmware
• Looking for artifacts in publicly available update code and update processes
• Identify any open-source dependencies related to firmware and hardware technology stacks 

Ultimately, the supply chain provides a great avenue for attacker reconnaissance since there are many suppliers and sub-suppliers (or even logistics partners) who could have code available or that may unintentionally expose sensitive information that could be used later in an attack. 

Resource Development

Resource Development allows an adversary to acquire infrastructure that will support active phases of an attack. 

• Acquiring servers or implanting firmware backdoors in networking devices such as switches or bare-metal cloud services through:
  • Directly manipulating source code repositories used by supply chain vendors to introduce malicious code or vulnerabilities
  • Manipulate a vendor or supplier’s software or firmware update processes
  • Coerce developers or manufacturing staff to introduce malicious code within a product 

Initial Access

Supply chain and firmware attacks truly change the game when it comes to initial access. Instead of a direct assault on an enterprise, supply chain threats arrive in the guise of trusted vendor products and code. 

• Targeting any of the dozens of suppliers and subcontractors that work on a product prior to delivery to the customer
• Directly inserting implants in vendor code, manipulating update processes, attacks on vendor signing processes
• Changing low-level device configurations
• Manipulating code in transit or delivery
• Targeting a variety of vulnerable components such as device management protocols (e.g. IPMI, Redfish, etc), debug interfaces, or management web interfaces

It is important to note that VPNs, routers, and security appliances have become some of the most common initial access vectors for advanced adversaries and virtually all major ransomware operators. 

Execution

Attackers have many ways to gain code execution through firmware or supply chain attacks. Any implants inserted during the manufacturing process can instantly give an attacker code execution under the guise of valid code. Likewise, Direct Memory Access (DMA) injection or attacks against System Management Mode (SMM) can give attackers code execution below the level of the operating system. Firmware or supply chain vulnerabilities can also often be remotely exploitable. And as with all types of code, attackers can use social engineering to trick users into running the attacker’s code to exploit firmware vulnerabilities or trick them into performing malicious firmware updates.

Persistence

Persistence has always been a key driver behind supply chain and firmware attacks. 

• Supply chain attacks by nature will compromise code that an enterprise considers to be “valid” or trusted. If the supply chain is compromised, an organization’s reimaging efforts may only serve to reinfect a given device. 
• Firmware code is integrated into system components themselves, instead of residing on traditional storage drives. This not only hides the attacker’s code from traditional security scans but also ensures the code will persist even if a system’s drives are completely erased, re-imaged or even replaced. 
• Attackers can establish persistence by gaining control of a device’s boot process to ensure their malicious code is always run during startup. Firmware rootkits and vulnerabilities such as BootHole can allow an attacker to execute their code before the operating system is even loaded.

Privilege Escalation

IT infrastructure products from PCs to virtualization software rely on a wide range of highly privileged code, options, and settings that control the fundamental nature of how a given asset works. 

• A kernel-level rootkit can give attackers access to the most trusted layer of the operating system known as Ring 0. 
• Malicious bootloaders can allow attackers to gain control of the boot process to load an attacker-controlled OS or patch an existing OS to disable protections. 
• Gaining control of System Management Mode (SMM) can allow attackers to run malicious code at runtime that is completely invisible to the higher-layer operating system. 
• Attackers can escape from VMs to access the underlying host.  

These are just a few of the ways that attackers can abuse low-level vulnerabilities to gain unexpected privileges that can be very hard to detect with traditional security controls. 

Lateral Movement

As covered earlier, network devices have proven to be incredibly popular targets for attackers. In addition to initial access, these assets provide attackers with the ability to spread to other hosts and areas of the network. This can allow ransomware operators to spread from a single device to hundreds or thousands. Attackers have also used IoT devices as a way to easily move across a network. This is because IoT devices and network devices both often lack the ability to support local security agents. 

Attackers can also use a vendor’s management capabilities in order to spread from asset to asset. For example, attackers can target BMCs, IPMI, or Redfish as a way to control and spread across servers in cloud or datacenter environments. On laptops, attackers can likewise abuse diagnostic and management interfaces such as Intel Active Management Technology (AMT), a feature offered as part of Intel ME and CSME (Converged Security and Manageability Engine). 

Impact

Attacks are ultimately about the impact, and once again, this is another area where supply chain and firmware threats are in a class by themselves. One important factor is that supply chain attacks are often massive in scope by their nature. Instead of infecting devices one by one, attackers can use the supply chain itself to deliver malicious code to thousands of devices. From an enterprise perspective, this can mean that entire fleets of devices could be compromised. The low-level nature of supply chain and firmware code also provides the ideal conduits to steal data or cause direct damage. The same ability to sit below the OS and to use or abuse networking or management interfaces can provide stealthy mechanisms for data exfiltration. Access to firmware either at the system or component level can allow attackers to permanently disable devices.

Hopefully, these examples have helped to illustrate some of the big picture around the importance of the below-the-OS attack surface and supply chain security. Supply chain and firmware attacks are not individual techniques or discrete attacks. They are fundamental security disciplines that cut across all types of devices and assets and across virtually all phases of the attack lifecycle. This is why it is imperative to have a lifecycle approach to supply chain security. At Eclypsium, this is our specialty, and if you would like to learn more, please drop us a line at info@eclypsium.com.

Further reading:

• Check out our full ATT&CK whitepaper to learn more about how Eclypsium protections apply to the ATT&CK framework.

• Read our whitepaper, Network Infrastructure on the Front Line for a deeper analysis of recent attacks on network infrastructure and how to defend against them. 

The post Applying ATT&CK Methodology to Hardware and Firmware appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

This is still a developing story, but here are the important points:

What to know

• The current activity is likely coming from a single threat actor, with the first observed threat activity on September 28. 
• Cisco announced a zero-day vulnerability on October 16 (CVE-2023-20198) with no patch available as of this writing. The current guidance is to disable the HTTP Server feature on all internet-facing systems (or set access control lists) and check for indicators of compromise. 
• As of October 18th, the internet scanning firm Censys has found more than 40,000 devices showing indicators of compromise. One Shodan search found more than 140,000 Cisco IOS XE Web UIs exposed to the internet (potentially making them vulnerable).
• Eclypsium detects the implant that is part of the ongoing mass exploitation campaign, along with other threats.

Key takeaways

• In this case, the speed at which the threat actors have compromised vulnerable devices is astounding—compromising tens of thousands of infrastructure devices before the vendor has released a patch. Updating network infrastructure can affect the availability of business-critical applications, so even when a patch is available it will require careful attention on the part of network operations teams. Unlike modern server environments, the patching process for network infrastructure vulnerabilities is complex due to downtime involved.
• The wide scope of the discovered exploits shows that many, many organizations are still not following best practices of either removing management interfaces from the internet or implementing zero-trust network access controls. This is why CISA issued Binding Operational Directive 23-02 in June, requiring federal agencies to mitigate these risks. Even if you’re not in the federal government, CISA’s note is worth a read. We all need to reflect on why many attacks on important IT infrastructure are successful because of poor security hygiene. 
• One reason attackers target network devices is because they are by their nature connected to internal networks—perhaps thought to be unexposed to the internet. Many vulnerabilities are deprioritized because they are mistakenly thought to be unreachable by attackers, such as the baseboard management controller vulnerabilities that Eclypsium research discovered earlier this year. 

Eclypsium customers can detect Cisco IOS XE exploits

Based on analysis details of the exploit provided by Cisco Talos, Eclypsium has added detection capabilities for the implant used in the CVE-2023-20198 mass exploitation campaign. 

Network infrastructure is under attack! 

So far in 2023, there have been a number of attacks against network devices of which this is the latest. We’ve had Volt Typhoon, JaguarTooth, and BlackTech campaigns from APTs. But we’ve also seen ransomware groups Akira, CACTUS, FIN8, and LockBit 3.0 targeting network appliances.

Eclypsium is on a mission to secure the supply chain for your IT infrastructure, part of the broader digital supply chain. What we do addresses a critical gap in cybersecurity programs: Eclypsium provides security teams the ability to inventory assets and their low-level components, harden their hardware and firmware attack surface, and detect below-the-surface threats that evade EDR. CVE-2023-20198 and the mass exploitation campaign that we’re seeing for this zero-day vulnerability is just an example of why a new approach is needed to protect network infrastructure. 

Finally, threat detection for network devices

As you know, EDR is not supported on network infrastructure. That’s one reason Eclypsium has expanded our firmware OS integrity and threat detection capabilities for network devices, and last month announced new features that monitor for changes in firmware and OS binaries, modified configuration and backup files, reverse shells, persistence modules, and more. Eclypsium brings EDR-like capabilities to network infrastructure and helps organizations to detect and respond to events like the mass exploitation of CVE-2023-20198. 

This is a supply chain security problem

While we wait for all enterprise technology products to be shipped secure by design, organizations need to have a “trust but verify” approach to the digital supply chain, including for network devices. Defenders need to anticipate and manage supply chain risk, including zero-day vulnerabilities in components such as IOS XE firmware. Simply scanning for known vulnerabilities alone is insufficient. Additional device integrity checks and continuous monitoring can add important compensating controls to detect compromise. 

If you are ready for a new approach to protecting network infrastructure, please schedule a demo. You can also walk through the key capabilities of our platform in this product tour (no form fill required).

The post Cisco IOS XE Zero-Day: Network Supply Chain Vulnerabilities Underscore Lack of Threat Detection appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

For more insights on hardware hacking, check out the webinar: Spooky Experiments – Building Your Own Security Research Lab.

With the help of the Eclypsium research team (and others mentioned below), I set out to look inside some of the Android TV devices on the market today. In 2023 in particular there have been many publications pointing out that Android TV devices come pre-installed with malware. It should be noted that the process and the findings below serve two purposes:

1. Describe the process for validating the digital supply chain of devices so others can also learn and replicate on their own.
2. Underscore just how difficult it is to validate the digital supply chain manually and without cooperation from all entities in the supply chain.

Attacking The Supply Chain With Pre-0wned Devices

Supply chain threats come in many different forms, including attackers placing malware and/or backdoors inside firmware or software at some point in the process before the device is acquired by the end-user or organization. Android devices serve as a great example of this type of threat. Previous research has observed several different manufacturers and threat actors specifically targeting Android TV devices (though some of the same malware can also be found in other Android devices, such as phones and tablets). The root of the attacks likely stems from the process of getting an inexpensive device to the Android TV market. As some suggest, there are base versions of Android and Android apps that are used on Android TV devices that have malware and end up in the hands of consumers, in some cases I believe without the intermediate manufacturers even knowing they contain malware. I’ve also observed situations where manufacturers are likely aware that applications included on the device contain malware, and may even conspire with malicious app developers to offer software updates. This means at any point a device may be “clean”, but subsequent updates to seemingly benign apps come loaded with malware. I also believe that we’re in a cat-and-mouse game with malware authors. As they tear down and rebuild, the IoCs change, making them more difficult to detect. There are also theories that there is cooperation between parties to ensure that malicious software to generate ad revenue is placed on Android TV devices, allowing them to be sold at more affordable prices (however, in this scenario your data is the product being collected and sold) Suffice it to say, be aware if you are shopping for Android TV devices.

As an exercise, we analyzed a few different models of Android TV devices and checked them against existing research (highlighted in the next section). The goal of this post is to document the process so people can validate their devices and ensure they are not “pre-0wned”. 

History of Android TV Pre-0wned Devices

One of the things that led me down the path of exploring Android TV malware is the re-occurrence of the headlines warning people of the dangers of these types of devices. Below are some highlights:

• 2017 – It started with ransomware being discovered on Smart TVs (thankfully this did not take off). This particular type of malware seemed to be short-lived, infecting consumer Smart TVs, locking them up using a “screen locker”, and displaying a message to the user that they must pay a ransom if they want to use their TV again. In 2017 several different strains of Android malware, such as CopyCat, were infecting devices, mostly phones at this point in time. I also traced back a suspicious Android app that has gone through phases of being malicious; being labeled as benign, then back to malicious called “Adups”. I discovered newer versions of Adups on some of the devices we analyzed, noting that while they may not appear to be malicious at this point in time, they could auto-update and become malicious. This is especially concerning as most Android TV devices do not come with protections or detections for such threats. 

• January 2023 –  Thanks to independent research, and further analysis from MalwareBytes (and others), the T95 Android TV device was identified as hosting several different malicious apps. Security researcher Daniel Milisic created a Github repository that serves as an excellent point of reference to both identify malware on these devices and clean your device if it has been infected. This research also points to CopyCat as the malware (or variant) that was deployed.
• April 2023 – The popular YouTube channel Linux Tech Tips (LTT) published a video with similar findings as the research from January 2023. The LTT research was shared with Daniel Milisic for validation.
• May 2023 – The EFF issues a report stating “Certain Android TV Box models from manufacturers AllWinner and RockChip, available for purchase on Amazon, come pre-loaded with malware from the BianLian family, a variant of which we investigated last year.”
• In this very same timeframe, TrendMicro issued a report on Android malware it dubbed Lemon, stating: “We identified some of these businesses used for different monetization techniques, such as heavy loading of advertisements using the silent plugins pushed to infected phones, smart TV ads, and Google play apps with hidden advertisements.” 
• September 2023 – An article was published by Dr. Webb that caught my attention and highlighted Android TV-based malware (with malware origins, in this case, tracing back to Mirai). 
• October 2023 – Human Security releases a research report detailing Android TV analysis, including the identification of two new strains of discovered malware dubbed “Badbox” and Peachpit”. For good measure, Wired runs an article on the dangers of Android TV devices with backdoors. 

Why Target Android TV Devices?

Attacking Android TV boxes provides attackers with certain advantages. The advantages below are also ubiquitous in nature across other platforms found in enterprise computing (including UEFI, BMCs, and network devices):

1. Stealth – If the malware can be embedded early in the manufacturing process it can go unnoticed for some time. Most consumers do not run anti-malware software on Android TV devices, nor do they bother to look and check the supply chain and/or security of the devices.
2. Persistence – Android TV devices by nature are connected to the Internet as the primary goal is to stream TV and movies. The Android applications can then automatically update and/or pull down more malware onto the systems at any time.
3. Ubiquity – There are hundreds of choices for Android TV boxes, at very reasonable prices. This means the attackers can cast a wide net by pre-infecting various models, ending up in the homes of thousands of users across the globe. 

Analyzing Android TV Devices

After hearing and reading about Android TV devices being pre-installed with malware, I wanted to see for myself. I mentioned my curiosity about Android TV devices to the Eclypsium research team and they too were intrigued and even joined in on some of the fun (along with my good friend Larry Pesce at Finite State). Several of us purchased at least one of the following devices:

1. X88 Pro 10
2. T95
3. ONN Android TV 4K
4. Magiccube 

Most research papers and articles I’ve read skip right to the Android malware they found on these devices. In this article, I’d like to walk you through how to approach evaluating the security of hardware devices so you can apply this knowledge to any related project, including checking your own Android or other such devices for evidence of pre-installed malware.

The ONN Android TV 4K

The first task is to take apart the device and expose the electronics. As you can see in the above image this device was not intended to be user serviceable as there are no exposed screws (or any screws underneath the sticker containing the model and serial numbers). Before I do any tinkering with the software, I like to know what I’m working with. Specifically, I like to see if there is a header available for either UART or JTAG. This provides some level of diagnostics, and potentially recovery if something goes wrong. While there are specialized tools for popping open the plastic cases I prefer my super-dooper-leet-reverse-engineering tool:

I used this tool on the ONN Android TV device to not only remove the board from the plastic case but also remove all of the heat shielding (that thankfully was not soldered or glued in place, which is sometimes the case). 

To get more information about the components, I uploaded the photos to Google Photos and used the “Copy text from image” feature to provide me the text to copy and paste into Google and find more information, such as the specifications for the eMMC chip. I also identified the UART header and soldered on a pin header for access to the serial console. 

It turns out that access to the Android debugger on the ONN Android TV device was limited to non-root access out-of-the-box. This means I could use the Android Debugger (adb) shell to gain access, but unable to perform a full analysis of the file system and look for indicators that have been previously published (or discover new ones) as permissions were limited. I tried, unsuccessfully, to root the Android device by several different mechanisms, and managed to corrupt the boot loader and was left with a device that only booted to a splash screen that displayed “ONN”. This is fairly common when doing this type of work, and I definitely learned the hard way that having more than one of the same device is helpful in this situation. Not wanting to end up with the world’s largest Android TV device collection, I proceeded with further hardware analysis.

Since my goal was to review the file system (not caring about getting Android root like many on the Internet that use this level of access to customize the device, remove spyware and malware Android apps, and remove apps that you are unable to remove via the Android TV interface), it was time to remove the flash storage (eMMC) chip. Once the chip is removed it can be read with an eMMC flash reader (such as this one: Rakstore EMMC153 EMMC169 Test Socket USB Reader). With the assistance of Larry Pesce (Product Security Research and Analysis Director at Finite State), a hot air rework station, and some desoldering wick, we successfully removed the chip (this is the easier part, re-installing the chip on the board is the really tricky part). We managed to dump the contents of the eMMC chip, however, the file system was encrypted. While further analysis is required to unlock the file system for this particular device I turned my attention to the other devices. If findings are produced from further research I will post a follow-up article sometime in the future.

The “Magiccube”

The same process was followed for the Magiccube device as we did for the ONN Android TV (eMMC was removed and placed in a reader and file systems were copied). The filesystem was not encrypted on this device, allowing for offline analysis. I mounted the file system using the following Linux commands (sdb25.img was the user data partition from the eMMC flash):

First, verified the file system, in this case it was ext4:

$ sudo parted sdb25.img print
Model:  (file)
Disk /home/paulda/src/magiccube/sdb25.img: 27.6GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags: 

Number  Start  End     Size    File system  Flags
 1      0.00B  27.6GB  27.6GB  ext4

Next, run kpartx to map the file system dump to a loop device (required for mounting):

$ sudo kpartx -a sdb25.img 

Next, mount the partition to a directory:

$ sudo mount -o loop,rw /dev/loop0 sdb25

I did not find any of the previously documented IoCs on the file system (e.g. there was no “Corejava” directory). I did run some of the Android apk packages through VirusTotal to see if I could find anything suspicious. One package, com.apkpure.aegon, clearly contained some sort of ad tracking. I also found some of the URLs below on a few different ad-blocking deny lists:

Having not found direct evidence of malware, I moved on to the next device.

The T95

The T95 Android device came with a version of Android that allowed us to use the Android Debugger (adb) as root over the network, retrieve files, and effectively hunt for malware. I did observe some unique behavior with the T95: after I enabled debugging, and then rebooted, I could not connect over the network to the adb service on TCP port 5555 unless I went into developer settings and enabled USB debugging (then it proceeded to listen on port 5555). I then connected as follows:

$ adb connect 192.168.1.150
connected to 192.168.1.150:5555

$ adb devices -l
List of devices attached
192.168.1.150:5555     device product:walley model:MBOX device:walleye transport_id:1

$ adb shell
walleye:/ $ 

$ adb root
restarting adbd as root

$ adb shell
walleye:/ #

The following command allowed me to dump a list of installed packages as I was looking to match these to known IoCs:

$ adb shell pm list packages -f
package:/system/app/TvdVideo/TvdVideo.apk=com.softwinner.TvdVideo
package:/system/priv-app/CtsShimPrivPrebuilt/CtsShimPrivPrebuilt.apk=com.android.cts.priv.ctsshim
package:/system/priv-app/GoogleExtServices/GoogleExtServices.apk=com.google.android.ext.services
package:/data/app/com.google.android.katniss-cge_xXeW17WhrGeW3nufDg==/base.apk=com.google.android.katniss
package:/system/priv-app/TelephonyProvider/TelephonyProvider.apk=com.android.providers.telephony
package:/system/priv-app/DynamicSystemInstallationService/DynamicSystemInstallationService.apk=com.android.dynsystem
package:/system/priv-app/CalendarProvider/CalendarProvider.apk=com.android.providers.calendar

While several of the Android packages and network traffic from this device were suspicious, I traced it back to references to adware. The “Walleye” reference is from the Pixel 2 version of Android, and this device also contained some test keys. I did not find any direct evidence of malware that previous researchers have found on the T95. My guess is that this device has a newer build that has removed traces of the previously discovered malware.

The X88 Pro 10

The X88 Pro 10 is similar to the other models that have been analyzed, with the exception of the SD Card reader. I discovered the article TV-box mania: X88 PRO 10 (RK3318) contained a tutorial that allowed for the device to boot a version of Linux directly from the SD card and contained a menu system that allows you to dump the contents of the onboard eMMC storage to the SD card. In the context of the tutorial, this was to create a backup. For our purposes, we can use the backup to perform analysis, a little easier than de-soldering and also preserves the device. I was able to carve out the user data partition from the image using the following process:

First, I printed out the partition in the image dump file:

$ sudo parted x88pro10.img print
Model:  (file)
Disk /home/user/src/x88pro/x88pro10.img: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name
 1      8389kB  12.6MB  4194kB               uboot
 2      12.6MB  16.8MB  4194kB               trust
 3      16.8MB  21.0MB  4194kB               misc
 4      21.0MB  25.2MB  4194kB               dtbo
 5      25.2MB  26.2MB  1049kB               vbmeta
 6      26.2MB  93.3MB  67.1MB               boot
 7      93.3MB  97.5MB  4194kB               security
 8      97.5MB  198MB   101MB                recovery
 9      198MB   601MB   403MB                backup
10      601MB   1003MB  403MB   ext4         cache
11      1003MB  1020MB  16.8MB  ext4         metadata
12      1020MB  1021MB  1049kB               baseparameter
13      1021MB  1038MB  16.8MB               logo
14      1038MB  4301MB  3263MB               super
15      4301MB  15.8GB  11.5GB  f2fs         userdata

Next, I used sfdisk to get the offsets:

$ sfdisk -d x88pro10.img 
label: gpt
label-id: 035B0000-0000-4C35-8000-04110000586F
device: x88pro10.img
unit: sectors
first-lba: 34
last-lba: 30777310
sector-size: 512

<snip>
x88pro10.img15 : start=     8400896, size=    22376415, type=1D0B0000-0000-453D-8000-2D3300005371, uuid=87340000-0000-4F30-8000-48C9000041B0, name="userdata"

Segment 15 contained the user data, taking the offsets and multiplying them by 512 produces the sectors needed to mount just that segment:

$ echo $((8400896 * 512)) $((22376415 * 512))
4301258752 11456724480

Next, mount the partition with the specified offsets:

$ sudo mount -o loop,offset=4301258752,sizelimit=11456724480 x88pro10.img userdata

However, this process also produced an encrypted file system as you can see below:

As it turns out, I should have looked at using the Android debugger (adb) first! For reasons I have not yet determined (could it be a firmware update that blocked this?) I could not connect to the Android debugger over the network. However, I connected a USB 2.0 cable (USB-A to USB-A 2.0 cable) and was able to interact with the Android debugger via USB. I can confirm that this model does have indicators that it has been pre-infected with malware. Since the C2 infrastructure had been dismantled at the time of this writing, the next stage of payloads was not delivered to the device. I did find evidence of malware that matches previous analysis, including:

• Both the /data/system/Corejava directory and a file named /data/system/shared_prefs/open_preference.xml were present on the system
• The /data/system/Corejava directory only contained a file named “e.l” and an empty subdirectory called “node”
• When the device boots up, it attempts to resolve one of the domains used to get the later staged payloads called “cbphe.com”. Since this domain no longer resolves, it is unable to complete the malware infection.

This does not mean that we are in the clear. At any time the C2 could come back to life and re-infect this device. There is also some process that is triggering the stage 0 payload to attempt to pull down the remaining malware. Previous researchers have traced this back to a process called “system_server”, and at this time no further analysis or answers could be found in my research. Daniel Milisic states this in his write-up: “The final bit of malware I could not track down injects the system_server process and looks to be deeply-baked into the ROM. It’s pretty sophisticated malware, resembling CopyCat in the way it operates. It’s not found by any of the AV products I tried — If anyone can offer guidance on how to find these hooks into system_server let me know.”

At this point, if we were to continue to use the device, I recommend it be wiped clean and run Linux (as described above) or use the clean-up scripts from Daniel Milisic.

Conclusion

Hunting for supply chain threats is tricky business and time-consuming. Most users may not go through the trouble of analyzing their devices to make sure it is not pre-infected during the manufacturing process. This does not only apply to Android TV devices since all the devices we use (personally and in the enterprise) could have similar supply chain security issues. While security researchers are working tirelessly to identify these threats, attestation of hardware and software during the manufacturing process would help identify these issues before they reach the consumer. Of course, the companies involved in the production of these devices would have to participate in such programs, validating and attesting to the security as they go. Thankfully there are third parties, such as ourselves, that are working every day to provide insights into the device supply chain and identify vulnerabilities and threats, hopefully before they have a negative impact. 

Resources and References:

• ONN 4K Box https://www.exploitee.rs/index.php/ONN_4K_Box – This page offered up some tips on analyzing this particular device, however, I believe it was an older hardware model than the one we recently acquired.
• Rooting an ONN 4k – https://github.com/amit-raut/Onn.-4k-Streaming-Box-Rooting-and-Remote-Button-Remapping/blob/main/README.md – I just want to point out that this did not work on the newer ONN 4K device, essentially I bricked it trying to follow this guide. Consider yourself warned!
• T95 Android TV (Allwinner H616) includes malware right out-of-the-box https://www.reddit.com/r/Android/comments/101k0eg/t95_android_tv_allwinner_h616_includes_malware/ – A detailed account from a Reddit thread.
• Mirai variant infects low-cost Android TV boxes for DDoS attacks https://www.bleepingcomputer.com/news/security/mirai-variant-infects-low-cost-android-tv-boxes-for-ddos-attacks/ – Bleeping Computer coverage of the Human Security research.

Special thanks to the entire Eclypsium research team and Larry Pesce who assisted me with this research.

Tools and Commands TL;DR

This section is a quick recap of commands and tools used in the blog.

sudo parted sdb25.img print

• sudo: Run the command with superuser privileges.
• parted: A Linux utility used to manipulate disk partitions and view partition tables.
• sdb25.img: Specifies a disk image file that parted will operate on.
• print: Displays the partition table of the specified disk image.

sudo kpartx -a sdb25.img

•  kpartx: A tool that’s part of the multipath-tools suite, used to create device mappings for the partitions of a device or a disk image.
• -a: This option tells kpartx to add mappings.
• sdb25.img: This is the disk image file for which you want to create partition mappings.

sudo mount -o loop,rw /dev/loop0 sdb25

• mount: A Linux utility used to mount file systems.
• -o loop,rw: Specifies mount options.
• loop: Indicates that the file/device should be mounted as a loop device. This is typically used to mount image files directly.
• rw: Mount the file system with read-write access.
• /dev/loop0: Represents a loopback device. These devices are used to mount file systems that are not associated with a physical device like disk images.
• sdb25: Specifies the mount point, which is the directory where the file system will be accessible once mounted.

adb connect 192.168.1.150

adb devices -l

adb shell

adb root

adb shell

adb shell pm list packages -f

• adb: Android Debug Bridge, a tool used for communication with Android devices.
• connect: Connects the ADB service to an Android device or emulator using a specified IP address.
• devices: Lists all connected Android devices and emulators.
• -l: Provides a long listing, offering more detailed information about each device.
• shell: Opens a command-line interface on the connected Android device or emulator.
• root: Restarts the ADB daemon with root privileges on the connected device, allowing elevated permissions.
• pm: Package Manager command-line tool.
• list packages: Lists all packages (apps) installed on the device.
• -f: Shows the associated APK file for each package.

sfdisk -d x88pro10.img

• sfdisk: A Linux utility used for displaying and manipulating partition tables.
• -d: Dumps the partition table in a format that can be used as input to sfdisk for replication.
• x88pro10.img: Specifies a disk image file that sfdisk will operate on.

echo $((8400896 * 512)) $((22376415 * 512))

• echo: A command used to display messages or output.
• $((…)): Arithmetic expansion syntax in the shell, which evaluates the arithmetic expression inside the double parentheses.
• 8400896 * 512: Multiplies 8400896 by 512.
• 22376415 * 512: Multiplies 22376415 by 512.

The post Android TV Devices: Pre-0wned Supply Chain Security Threats appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

And while this has always been the case, the threat landscape has gotten even more intense in the years following COVID-19. Advanced threat actors have ramped up efforts to steal sensitive medical research, and ransomware groups have sought to extort hospitals by disrupting clinical systems. In both cases, the often overlooked supply chains and firmware within critical devices have played a major role in how attackers gain initial access into a network and subsequently maintain persistence, evade security, and cause damage. 

Our new paper, The Threat Landscape for Healthcare Organizations, takes an in-depth look at the threat landscape facing healthcare organizations today. We look at the different threat actors that are involved, their motivations, and the recent trends in how they operate. Most importantly, we look at the evolution of attacks that are going “below the operating system” or BtOS. We look at real-world examples of how this strategy is used across multiple phases of real-world attacks, including a demonstration of the same techniques used in the wild, one that shows how in under three minutes, an attacker can go from the Internet to a critical internal medical device inside a hospital, for example.

The goal of the paper is to give healthcare teams visibility into how adversaries are causing damage and imposing real-world clinical risk, so that teams can make smart, threat-informed decisions to protect their critical data and systems. Here are some of the key takeaways:

The Threat Landscape Most Healthcare CISOs Don’t See

Attackers naturally gravitate to the areas where their actions will have the biggest impact while facing the least resistance. In recent years, attackers have found a way to meet both of these goals by targeting the supply chains of critical assets and clinical devices. Specifically, actors have targeted the highly privileged code, components, and settings that reside below the operating system (BtOS) on devices both externally-facing and within medical environments 

This trend accomplishes two critical things for attackers – it allows them to attack below the well-defended operating system layer, while also taking advantage of the trust in an organization’s technology vendors. 

Over the years, the industry has put considerable effort into making operating systems more secure and resilient to attacks. Likewise, virtually all traditional cybersecurity defenses look for threats running at the OS level, and those same security tools often depend on the operating system for their visibility and detection of threat activity. By driving the attack below the operating system, attackers can shift the battle away from a hardened target with many defenses to an area that is comparatively unguarded, yet provides even more stealth, power, and persistence. 

By targeting the technology supply chain, adversaries can insert malicious code within the products or updates even before they are delivered to the clinical environment.  Every piece of equipment from laptops, to servers, to networking infrastructure, to medical devices all rely on complex technology supply chains. A compromise at any supplier or sub-supplier can potentially put the integrity and security of the entire asset at risk. 

Attacks in Clinical Environments

Thus far, we have covered why attacker techniques are shifting. Yet it is important to understand how these techniques apply in real-world scenarios, specifically for healthcare organizations. 

• Every Asset Has a Supply Chain – Supply chains are not just about technology – they also represent chains of trust. And each of these points of trust can potentially be a point of attack. Every underlying technology within a supply chain introduces the potential for problems, both intentional and unintentional. Each supplier or sub-supplier can introduce vulnerabilities within critical code that can lead to a compromise of the asset. External attackers or malicious insiders can embed malicious code or backdoors within underlying components, systems, or product updates. Products can be potentially tampered with by any party that controls the asset before it is delivered to the ultimate buyer. This means that clinical IT and Security teams need to be able to verify the true integrity and posture of every asset down to the lowest level of code.

• Firmware is Everywhere – Healthcare IT and Security teams must protect an incredibly wide range of devices, and almost all of them can be critical to a hospital’s operations. This can include IoMT devices ranging from basic patient monitors to the most advanced diagnostic imaging systems. PACS and EHR systems carry critical data. Likewise, healthcare organizations rely on a wide range of IoT and OT devices. While an inconvenience for most organizations, a failure of HVAC or refrigeration systems in a hospital can be life-threatening. While these devices may or may not have a traditional OS, they all have firmware. For an attacker looking to cause damage and disruption, firmware is a universal way to completely disable a target device.
  
• Attacks Cut Across the Organization – Once the tactics of sophisticated state-based attackers, BtOS techniques have become mainstream and are now seen in everything from APTs to the most widespread, opportunistic ransomware groups. Notably, vulnerabilities within the firmware of network devices such as VPNs, firewalls, and network controllers have become some of the most common initial access vectors for attackers. This entry point provides the ideal location for an attacker to spread, again using very well-known vulnerabilities and exploits. As the attacker moves to new devices, vulnerabilities lying below the OS allow attackers to install firmware implants and backdoors that make it possible to establish long-term persistence and security evasion. And as we’ve mentioned earlier, attackers can then target the firmware to cause either temporary or permanent damage to a device.
  
• Clinical Impacts – Ultimately, as defenders, we care about how BtOS attacks can impact healthcare and clinical systems. The video below walks through one scenario and illustrates how readily available exploits and techniques can and are being used by attackers today in clinical environments. 

And while is this one example, the full paper digs into additional scenarios device firmware is being targeted, and how they can impact healthcare operations including:

• Loss of Patient Data – How firmware and BtOS techniques can be used to access data within EHR systems, PACS systems, and clinical SaaS applications.
• Financial Extortion –  The role of firmware in the context of ransomware attacks and other forms of financial extortion. This can include the ability to access or steal sensitive data, or the ability to disable critical systems.
• Destructive or Political Attacks – Unlike ransomware groups, some threat actors have no goal other than to inflict maximum and permanent damage. These attacks can cause long-term disruption to an organization’s ability to deliver care and can be incredibly costly in terms of recovery. 

To learn more, we encourage you to review the full paper available here. The paper gives far deeper insights into the adversaries currently targeting the healthcare industry and their motivations and techniques. Additionally, we provide a framework that security teams can use to build a BtOS security program that can help keep their organization and assets safe. With newer purpose-built technologies, vulnerabilities and threats BtOS are finally visible and can be proactively mitigated by those protecting medical environments. For additional questions, or to schedule a discovery call to explore this attack surface (and how to address it) further, please reach out to the Eclypsium team at info@eclypsium.com.  

The post How Healthcare Threats Are Going Low appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

While security teams have improved their defenses against ransomware, there’s still one gaping weak spot that attackers are targeting for initial access, persistence, lateral movement, and more—network infrastructure. 

State-sponsored APT actors continue to target network appliances, notably with the recent Volt Typhoon attacks against military targets, an APT28 campaign using JaguarTooth malware to target Cisco IOS, and BlackTech campaigns against multiple types of network routers (detailed in a joint NSA and CISA cybersecurity advisory).

In addition, this summer has seen a torrent of headlines about ransomware groups Akira, CACTUS, FIN8, and LockBit 3.0 targeting network appliances:

• In August, LockBit and Akira exploited a zero-day vulnerability on Cisco VPN appliances that were not configured for multi-factor authentication. It’s easy to say MFA is the solution, but it can be challenging to ensure compliance with your security policies. 
• In July, FIN8 installed webshells on nearly 2,000 unpatched Citrix NetScaler devices (6% of the vulnerable devices exposed to internet scans). It’s notable that the attackers were able to set up infrastructure for a mass exploitation campaign that outpaced defenders’ ability to patch since the update was released just days earlier. They installed webshells that persist even after the embedded OS is patched and rebooted. This last point is crucial because it requires careful investigation on the part of network administrators and security teams to inspect NetScaler access logs. FIN8 only started deploying ransomware recently, having previously been known for scraping data from point of sale systems.
• In June, Akira was discovered to be exploiting flaws in Fortinet VPN appliances including using a Python tool that chained vulnerabilities together.
• In May, CACTUS was reported to be attacking unspecified vulnerable VPN appliances.

This summer, the ransomware group FIN8 ran a mass exploitation campaign compromising 6% of vulnerable NetScaler appliances exposed to the internet.

This activity should not come as a surprise. We published research last year that warned about these types of attacks against network infrastructure and showed that: 

1. It was possible to use off-the-shelf C2 frameworks on load balancers
2. Malware targeting these devices could persist across updates and reboots
3. It was possible to infect devices so deeply that even a clean wipe and reinstall was not sufficient remediation
4. These aforementioned goals were not beyond the skill of a motivated attacker who simply read through vendor documentation and used existing toolkits 

Why Is Threat Detection on Network Devices So Hard?

Unfortunately, the status quo for security teams makes detecting these types of intrusions very difficult. For one thing, these appliances do not have EDR. There are limited and inconsistent detection and logging capabilities across makes and models. File integrity monitoring to alert for changes to backup and configuration files are also generally substandard or nonexistent. 

Moreover, network devices are extremely varied and not well understood by security teams. These devices can be physical systems or virtual appliances deployed in a public cloud, each with their own unique firmware OS and configuration. Organizations often employ multiple types of network appliances as VPNs, gateways, firewalls, and load balancers—it’s a complex attack surface to defend! Network administrators who might be looking at the logs may not have the security expertise to understand when they are looking at an indicator of compromise. 

Addressing a Major Gap in Ransomware Defenses

Over the past several months, Eclypsium has been expanding firmware OS integrity and threat detection capabilities to network devices by Cisco, F5 Networks, Fortinet, Juniper, NetScaler, and Palo Alto Networks, and will continue to expand to other network device manufacturers. The new capabilities are designed to look for compromise by known and new threats on physical and cloud (virtual) network appliances, and include monitoring for changes in firmware and OS binaries, modified configuration and backup files, reverse shells, persistence modules, and more.

The new threat detection and integrity monitoring augments our existing supply chain vulnerability and risk assessment of network devices, bringing EDR-like detection and response capabilities to network infrastructure.

The short video below shows how the Eclypsium supply chain security platform detects active compromise of a NetScaler appliance exploiting CVE-2023-3519 which was used in FIN8’s mass exploitation campaign this summer. 

Network Infrastructure Has a Supply Chain Security Problem

As CISA Director Jen Easterly has said, organizations should expect IT products to ship securely by default. “We’ve normalized the fact that technology products are released to market with dozens, hundreds, or thousands of defects, when such poor construction would be unacceptable in any other critical field,” said Easterly. 

That ransomware groups and APTs are seeing so much success targeting network infrastructure gear indicates a supply chain security problem with enterprise IT infrastructure in general. IT and security practitioners cannot blindly trust all manufacturers to ship these network appliances without vulnerabilities and to have well established and secure update processes. Instead, defenders need to anticipate and control the supply chain risk. The old approach of network scanning alone is neither effective nor sufficient, as security operations teams are overwhelmed and can’t keep up with constant patching of critical IT infrastructure. Eclypsium adds continuous monitoring and device integrity checks that are needed as compensating controls to detect ongoing compromise. 

If you would like to take a look at our capabilities for protecting your network infrastructure, please schedule a demo. We also have a product tour that walks you through the platform (no form fill required). 

The post A New Approach to Defending Network Infrastructure from Ransomware Groups and APTs appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

What is CPU Microcode?

CPU microcode represents low-level instructions essential for the proper CPU functioning, acting as a bridge between the CPU’s architecture and the electronic circuits that execute instructions. Microcode resides directly on the CPU and translates higher-level instructions into operations that the CPU can understand and execute. Microcode enables manufacturers to fix bugs, improve performance, and address security vulnerabilities without the need for physical hardware changes or full-scale firmware updates. However, microcode can also introduce vulnerabilities, underscoring the importance of its management and security.

How is CPU Microcode Protected and Distributed?

To ensure the authenticity and integrity of CPU microcode, it is signed using digital signatures. binding the microcode to a specific manufacturer and preventing tampering during transmission or storage. The journey of a microcode update begins with the CPU manufacturer, such as Intel or AMD, where it is tested and ultimately signed and distributed. Some microcode updates are integrated into operating system updates. When you install a system update, it may include the latest microcode for your CPU. System and motherboard manufacturers may also provide microcode updates specific to their hardware. These updates are often bundled with BIOS/UEFI firmware updates. In some cases, microcode updates can be distributed automatically via operating system update mechanisms. This ensures that users receive critical microcode updates without manual intervention. For advanced users or in cases where automatic updates are not available, microcode updates can be manually installed by downloading the update from the manufacturer’s website and following their installation instructions.

Once obtained, microcode updates are applied to the CPU during the system’s boot process. The CPU microcode is loaded into the CPU’s microcode storage, replacing the previous version. This update process is designed to be transparent to the user and typically does not require any special user interaction.

Attacks Against The CPU

While updates to the microcode on your CPU can mitigate a number of bugs and vulnerabilities dealing with cache timing and speculative execution classes have been the security drivers behind updates and CPU architecture improvements. Below is a list of the more popular vulnerabilities related to CPU microcode and speculative execution:

• 2005 – 2017 – Branch Target Buffer Attacks and other CPU side-channel attacks: Colin Percival’s research demonstrated a practical attack on modern processors using the branch target buffer. This attack could potentially leak information and was demonstrated by extracting an OpenSSL RSA key. Several other papers on the subject were published during this time, however, mainstream attention was not garnered until Spectre and Meltdown were published in 2018.
• January 2018 – Spectre –  Researchers at Google Project Zero and elsewhere disclosed the Spectre vulnerability (CVE-2017-5753 and CVE-2017-5715). Spectre is a class of speculative execution vulnerabilities that affect a wide range of processors.
• January 2018 – Meltdown –  Researchers disclosed the Meltdown vulnerability (CVE-2017-5754), which primarily affected Intel processors. Meltdown allowed unauthorized access to kernel memory.
  • Note: In 2021 Spectre v2 Variants were disclosed (Spectre-BHB, Spectre-PR2, Spectre-SSB, and others)
• 2018 – RIDL (Rogue In-Flight Data Load) – Affecting Intel chips produced as early as 2008 the RIDL vulnerability was discovered by the same researchers that disclosed the ZombieLoad and Fallout vulnerabilities. RIDL be used to leak data from the vulnerable CPU’s various internal buffers (select regions of allocated memory used to store or load data). 
• May 2018 – Fallout –  Researchers disclosed the Fallout vulnerability (CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, and CVE-2019-11091), which exploited speculative execution to read data from Intel CPUs’ microarchitectural buffers.
• August 2018 – Foreshadow –  Researchers revealed the Foreshadow vulnerability (CVE-2018-3615 and CVE-2018-3620), which targeted Intel SGX (Software Guard Extensions), allowing attackers to extract sensitive information.
• May 2019 – ZombieLoad – Researchers disclosed the ZombieLoad vulnerability (CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, and CVE-2019-11091). It affected Intel processors and allowed attackers to exploit speculative execution to read data from other processes.
• January 2020 – CacheOut – CacheOut (CVE-2020-0549) was disclosed. This speculative execution attack could leak data from other processes or virtual machines running on the same CPU, even when SMT (Simultaneous Multi-Threading) is disabled.
• March 2020 – LVI (Load Value Injection) – Another speculative execution vulnerability that can be used to inject data into a victim’s transient execution. It affects Intel processors and can leak sensitive information.
• July 2023 – AMD Zenbleed – The Zenbleed vulnerability (CVE-2023-20593) is yet another speculative execution bug that allows data to be exfiltrated at high rate of speed (for this type of attack) clocking in at 30kb per core, per second. 
• August 2023 – AMD Inception – AMD’s Zen 3 and Zen 4 CPUs are affected by the ‘Inception’ vulnerability. Like many of the attacks on this list, inception is a side-channel attack that can lead to the exposure of secure data.
• August 2023 – Intel Downfall – Identified as CVE-2022-40982, Downfall is one of the most recent examples of speculative execution bugs, this time taking advantage of memory optimization features in Intel processors to access user data.

Applying Microcode Updates

Given the long list of vulnerabilities mitigated by CPU microcode updates, you may be motivated to start applying these to your systems. While it is recommended that microcode updates be applied, be mindful of the effects such as negative performance impacts. There are many variables to consider with respect to performance, such as the CPU and workload types, so risk-based decisions must be made. There are three ways in which microcode updates can be applied:

1. BIOS/UEFI Updates – Once the CPU manufacturer releases the microcode update typically the OEM that is using the affected processors will incorporate the microcode update into the UEFI update. This means in order to get the CPU microcode updated you will be applying the UEFI update and everything else that the OEM has included in it. Typically there are other firmware/software updates included in the UEFI update. 
2. Operating System Updates – Windows and Linux (as well as other operating systems such as macOS) will include microcode updates as part of the operating system updates. For example, when I updated one of my Linux systems the facilities within Linux successfully updated the CPU microcode such that I am no longer vulnerable to the Zenbleed vulnerability.
3. Manually By The User – It is possible to acquire the microcode update from Intel or AMD (as an example) and apply it manually using operating system-specific tools. There are resources at the end of this article that provide some details, but this is best left to advanced users.

How Eclypsium Can Help

Functionality provided by the Eclypsium platform includes the identification of CPU microcode, the version being used, and an indication of whether or not it is outdated. Keep in mind this functionality may be different depending on CPU architecture and type. The example below is a finding from our test platform that has identified 58 systems with outdated microcode:

The Eclypsium platform also identified several different vulnerabilities associated with outdated CPU microcode, including many listed in this article. Below we can see that 7 systems are vulnerable to the recent Intel Downfall vulnerability:

Conclusion

CPU microcode is an integral part of modern processors, serving to improve performance, fix bugs, and address security vulnerabilities. Its secure signing, distribution, and application processes are essential for maintaining the integrity and reliability of computing devices. We encourage users to stay vigilant and ensure that their systems receive timely microcode updates to benefit from the latest improvements and security enhancements provided by CPU manufacturers.

Resources

• Intel, AMD, VIA & Freescale CPU Microcode Repositories
• Debian Microcode Guide
• https://www.phoronix.com/news/Intel-12-May-2023-Microcode – Intel Issues New CPU Microcode Going Back To Gen8 For New, Undisclosed Security Update – The interesting note in this article is from an Intel official statement regarding the “NA” moniker on microcode updates that indicates the update was not security related.
• https://github.com/chip-red-pill/MicrocodeDecryptor – Security researchers were able to leverage vulnerabilities in Intel TXE and activated an undocumented debugging mode called “red unlock”.  This allowed the researcher to extract dumps of microcode directly from select Intel CPUs.
• https://www.linuxfromscratch.org/blfs/view/svn/postlfs/firmware.html – Good explanation of how microcode updates work, especially on Linux.
• https://github.com/AMDESE/amd_ucode_info – “amd_ucode_info.py provides a means to parse and display information about an amd-ucode (CPU microcode) container file in the format consumed by the linux kernel.”
• https://github.com/speed47/spectre-meltdown-checker – This script for Linux systems allows you to check for several of the speculative execution class of vulnerabilities listed in this article. Please note this is a free tool, provided by a group of volunteers and states: “This tool has been released in the hope that it’ll be useful, but don’t use it to jump to definitive conclusions about your security: hardware vulnerabilities are complex beasts, and collective understanding of each vulnerability is evolving with time.”
• Intel Microcode Update Guidance

The post Demystifying CPU Microcode: Vulnerabilities, Updates, and Remediation appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

One of the most significant changes in CSF 2.0 is the inclusion of a Govern function and an emphasis on cybersecurity supply chain risk management (C-SCRM) and secure software development.

Addressing Increasing Supply Chain Risk

Incidents in recent years having to do with the OpenSSL library, Log4j, and SolarWinds products (to name just a few) have emphasized the need to better understand and manage the risk that we are taking on when we use a particular technology, whether it be an open source software library or piece of network gear.

Part of the solution lies with vendors: requiring SBOMs, attestation that they are following secure software development practices, and in general asking that products be secure by design. 

But the other part of the solution lies with customers: Verifying that you are using libraries and repositories that are free from malware or backdoors, verifying that your devices contain authentic components that have not been tampered with, and then understanding and mitigating the risk that you knowingly accept. 

The latter part is what CSF 2.0 addresses with new C-SCRM controls. See the table at the bottom of this blog for a quick overview of the proposed Functions and Categories. 

Cybersecurity Supply Chain Risk Management in the CSF 2.0

The CSF 2.0 includes six functions: Govern, Identify, Protect, Detect, Respond, and Recover. The Govern function is new and includes a category for C-SCRM (GV.SC) that provides guidance on how to integrate supply chain risk management throughout your cybersecurity program. 

Here are the subcategories within C-SCRM: 

• GV.SC-01: A cybersecurity supply chain risk management program, strategy, objectives, policies, and processes are established and agreed to by organizational stakeholders (formerly ID.SC-01)
• GV.SC-02: Cybersecurity roles and responsibilities for suppliers, customers, and partners are established, communicated, and coordinated internally and externally (formerly ID.AM-06)
• GV.SC-03: Cybersecurity supply chain risk management is integrated into cybersecurity and enterprise risk management, risk assessment, and improvement processes (formerly ID.SC-02)
• GV.SC-04: Suppliers are known and prioritized by criticality
• GV.SC-05: Requirements to address cybersecurity risks in supply chains are established, prioritized, and integrated into contracts and other types of agreements with suppliers and other relevant third parties (formerly ID.SC-03)
• GV.SC-06: Planning and due diligence are performed to reduce risks before entering into formal supplier or other third-party relationships
• GV.SC-07: The risks posed by a supplier, their products and services, and other third parties are identified, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship (formerly ID.SC-02, ID.SC-04)
• GV.SC-08: Relevant suppliers and other third parties are included in incident planning, response, and recovery activities (formerly ID.SC-05)
• GV.SC-09: Supply chain security practices are integrated into cybersecurity and enterprise risk management programs, and their performance is monitored throughout the technology product and service life cycle
• GV.SC-10: Cybersecurity supply chain risk management plans include provisions for activities that occur after the conclusion of a partnership or service agreement

How Eclypsium Helps with C-SCRM

A lot of the industry is focusing on software supply chain security for custom-developed applications, but they’re not paying much attention to the infrastructure those applications run on. That’s the gap that Eclypsium fills. Eclypsium’s supply chain security platform protects the hardware, firmware, and software components of your IT infrastructure. Eclypsium previously collaborated with the NIST National Cybersecurity Center of Excellence (NCCoE) on SP 1800-34 demonstrating how C-SCRM should include IT infrastructure.

Eclypsium provides you with intelligence about your supply chain risk for IT products: laptops, desktops, servers, network gear, IoT devices, and software. You can inventory the hardware, firmware, and software components of your IT infrastructure products, prioritize risk—vulnerabilities and misconfigurations—and detect threats such as malicious binaries. We can even help you automate firmware updates. 

Eclypsium can help with other CSF 2.0 functions and categories as well, specifically: 

• Identify, Asset Management (ID.AM) – Providing you with inventories of hardware, firmware, and software assets, with the ability to generate associated SBOMs.
• Identify, Risk Assessment (ID.RA) – Helping you to measure risk from newly announced vulnerabilities and supply chain incidents and misconfigurations. You can also use Eclypsium to verify the authenticity and integrity of hardware and software prior to acquisition and use. 
• Protect, Platform Security (PR.PS) – Automating firmware updates for endpoints and servers, and providing guidance for other types of risk mitigations. We can also help you to harden this attack surface by highlighting misconfigurations that allow attackers to bypass system protections such as Secure Boot.
• Protect, Technology Infrastructure Resilience (PR.IR) – Protecting against unauthorized logical access and usage at the foundational firmware layer of your IT infrastructure devices. 
• Detect, Continuous Monitoring (DE.CM) – Detecting known and unknown threats at the hardware and firmware layers that can evade traditional endpoint security such as EDR. Eclypsium has the unique ability to monitor the integrity of firmware binaries for particular assets and groups of assets to detect indicators of compromise. Threat actors have persisted in environments for upwards of 18 months by hiding out in the firmware level, according to Mandiant. 

To learn more about the CSF 2.0 draft and specifically the new Govern function, join Eclypsium for our August 30 webinar: Tackling Supply Chain Security with NIST CSF 2.0 featuring Paul Asadoorian, John Loucaides and special guest speaker Rob Efrus.

The post NIST Cybersecurity Framework 2.0 Highlights Supply Chain Security appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

Overview

Amid several recently disclosed vulnerabilities in hardware/CPUs (including a voltage fault injection against AMD CPUs in Telsa vehicles, Zenbleed, AMD CPU attacks discovered by Tavis Ormandy, also a Google researcher, and Inception, a new attack also targeting AMD CPUs) Google research Daniel Maghimi disclosed vulnerabilities targeting Intel CPUs dubbed Downfall (CVE-2022-40982). Downfall exploits vulnerabilities associated with speculative execution, a technique used to boost performance, however, in some scenarios can be manipulated to access sensitive data. The vulnerability impacts 6th Skylake to 11th Tiger Lake generation Intel processors.

Detection

Soon after the news about the Downfall vulnerability broke out, our team added detection to the Eclypsium solution for the affected devices. This detection has been added to our platform (with a content update pushed to existing customers). 

Risk Analysis

This attack was used to demonstrate stealing cryptographic keys from Openssl, stealing secrets from the Linux kernel, breaking Intel SGX, and implementing a high bandwidth covert channel between separate processes. Since the “Meltdown” vulnerability was disclosed, this is the first hardware attack that enables a user to steal arbitrary data from the OS Kernel without relying on software vulnerabilities or Spectre gadgets.

To exploit this vulnerability and receive secret information that should be protected, the attacker needs to:

1. Run code on the same physical core.
2. Execute malicious code with specific instructions.
3. Perform an analysis of the results. 

Our recommendations for defenders are to check which processors are affected and install the latest microcode update. Intel has provided a comprehensive list of affected processors here. Systems running untrusted code or responsible for separating trust domains are at higher risk.

Additional Resources

• Downfall Attacks (https://downfall.page/)
• INTEL-SA-00828
• Threat Analysis Guidance for Gather Data Sampling (Intel)
• Downfall and Zenbleed: Googlers helping secure the ecosystem
• Chips & Salsa Episode 56: Interview with Daniel Moghimi about Downfall | Intel Technology
• New Downfall attacks on Intel CPUs steal encryption keys, data

The post Eclypsium Protection for “Downfall” Vulnerabilities on Intel processors appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

I really enjoy researching and acquiring “gadgets”. Recently, I spent a little time with Eclypsium’s research team discussing which hardware and software are most useful for security research, specifically hardware and firmware. The Eclypsium team has published extensive research in the past so I thought it would be excellent for the community to get an inside peek at some of the tools we use. Seasoned security researchers will probably recognize most, if not all, of the items on the list. And for others, this may read like a shopping list!

Hardware

• Chip whisper – Description: “The ChipWhisperer® ecosystem presents the first open-source, low-cost solution to expose weaknesses that exist in embedded systems all around us.” The researchers who recently discovered Tesla vehicles use AMD chips prone to glitching attacks likely used this device (or something similar).
  • See also the Chip shouter (“The ChipSHOUTER® (CW520) is a fully-featured Electromagnetic Fault Injection (EMFI) platform that can be used to discover and characterize vulnerabilities in embedded systems.”)
• Bus pirate – This is one of the preferred devices for communicating over SPI, but it does much more, including: “communicates between a PC and any embedded device over 1-wire, 2-wire, 3-wire, UART, I2C, SPI, and HD44780 LCD protocols – all at voltages from 0-5.5VDC.”. 
• Raspberry PIs – This includes a Raspberry PI 4, Raspberry PI Zero (finding these at the time of this writing is difficult due to supply chain issues), and a Raspberry PI Pico (and/or Pico W).
• Arduino – Along with some breadboards and patch cables.

• JTAGulator – Description: “an open source hardware tool that assists in identifying OCD interfaces from test points, vias, component pads, or connectors on a target device.” – Created by Joe Grand.
• Hantek 2D72 handheld voltmeter, signal generator, oscilloscope – This one looks much nicer than the beat-up one currently on my desk.
• Saleae – USB Logic Analyzer Saleae Logic 8 – “The Saleae Logic 8 is a powerful logic analyzer that lets you record and display signals in your circuit, so you can debug it fast.”

• Hak5 Packet Squirrel (and/or Ethernet Tap) – This is a great tool for capturing device traffic, such as firmware updates.
• Deadyprog SPI Flash Programmer – For those times when you need to re-flash the SPI!
• Flipper Zero – While there are many better alternatives to the hardware included with the Flipper Zero, I like the form factor. I can easily take a suite of tools with me wherever I go and “conduct experiments”. I installed the Unleashed firmware on the Flipper Zero and selected sets of files for Sub-GHz, RFID, NFC, and IR. Please use responsibly and ensure you have permission to hack things!

Software

• Ghidra – Reverse engineering framework.
• Binary Ninja – Another great reverse engineering framework.
• A ChatGPT (OpenAI) account (or subscription) – Very helpful to generate code as a starting point (and many other “things”).
• A subscription to VirusTotal
• EMBA – A firmware security analyzer.
• strings – Sometimes a simple Linux command such as strings is all you need to get started reverse engineering.

Other / Misc

The list below complements the previous two lists in many ways. Everything from note-taking to the proper footwear is covered below:

• Minuware ds213 oscilloscope
• Leatherman titanium multi-tool
• Battery-powered pencil soldering iron (many options are available)
• Jewelers loupe
• USB-C pass-through meters and protocol analyzers 
• Ifixit deluxe electronics repair kit
• Flir cameraphone 
• A box full of connects and solder
• Radiation detector (This fell in the category of “Don’t ask”)
• A variety of chemicals like acetone and protective gear
• Mission Darkness Faraday bags
• Laptop to run software for tools
• Smaller laptop that has plenty of ports
• Soldering/desoldering workstation with hot air gun (many options are available)
• USB microscope
• 3D printer (capable of high-impact polymer and carbon fiber)
• Desktop CNC mill
• GoPros (or other similar small cameras for recording work)
• High-storage battery in the 100-watt range
• Titanium pen
• High-quality lab notebook journal
• Powered self-stabilization selfie stick
• Tactical gloves with exterior lining (for electrical shocks)
• Workmen’s rubber-soled boots (such as one required to be worn in places like electric substations)

The post My Favorite Things: Hardware Hacking and Reverse Engineering appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.