ÆPIC Leak: Architecturally Leaking Uninitialized Data from the Microarchitecture
CPU vulnerabilities undermine the security guarantees provided by software- and hardware-security improvements. While the discovery of transient-execution attacks increased the interest in CPU vulnerabilities on a microarchitectural level, architectural CPU vulnerabilities are still understudied.
In this talk, we present AEPIC Leak: the first architectural CPU bug that leaks stale data from the microarchitecture without using a side channel. AEPIC Leak works on all recent Sunny-Cove-based Intel CPUs (i.e., Ice Lake and Alder Lake) and does not require hyperthreading enabled. It architecturally leaks stale data incorrectly returned by reading undefined APIC-register ranges. AEPIC Leak samples data transferred between the L2 and last-level cache, including SGX enclave data, from the superqueue. We target data in use, e.g., register values and memory loads, as well as data at rest, e.g., SGX-enclave data pages. Even if AEPIC Leak is a sampling-based attack, we introduce techniques to precisely influence from which page and offset the attack leaks from.
Our end-to-end attack extracts AES-NI, RSA, and even the Intel SGX attestation keys from enclaves within a few seconds. We discuss mitigations and conclude that the only short-term mitigations for AEPIC Leak are to disable APIC MMIO or not rely on SGX.
If you are interested in talks with happy ending, you better be off listening to some other topic. In this talk, not only there is no happy ending, there is no happy beginning and a very few happy things in the middle. This is not only because we destroyed 10 smartphones during our reserach project, but rather due to our daily struggles that come along with being a hardware reverse engineer. You don't know what a netlist is? Good, then there is still time to save yourself. Otherwise, in this talk, you will learn how to extract it from a chip, analyze it, and understand it - and why, despite everything speaking against it, this is actually quite fun and exciting. We will also provide (painful) insights into conducting real-world netlist reverse engineering by presenting a case-study on a completely unknown modern hardware design. Welcome to HAL!
In the last few years, containers have become a significant part of the cyber attack surface. Containers are now used by virtually all enterprises for day-to-day operations, making them a prime target for attackers. As a result, the number of cyberattacks involving containers has significantly increased. Consequently, security researchers and blue teams have to be familiar with this whole new world.
In our talk, we will be focused on Container escapes. Container escape is considered the "Holy Grail" of the container security attack world.
To truly understand the concept of containers and the specific attack vectors we need to dive into important principles in container internals focused on container capabilities. We'll describe how it actually works, how we can use specific container capabilities to pull off container escapes, and how to minimize the danger of this kind of attack.
“GIFShell” — Covert Attack Chain and C2 Utilizing Microsoft Teams GIFs
Seven different vulnerabilities and insecure design elements present in Microsoft Teams, can be leveraged by an attacker, to execute a reverse shell between an attacker and victim, where no communication is directly exchanged between an attacker and a victim, but is entirely piped through malicious GIFs sent in Teams messages, and Out of Bounds (OOB) lookups of GIFs conducted by Microsoft's own servers. This unique C2 infrastructure can be leveraged by sophisticated threat actors to avoid detection by EDR and other network monitoring tools. Particularly in secure network environments, where Microsoft Teams might be one of a handful of allowed, trusted hosts and programs, this attack chain can be particularly devastating.
Two additional vulnerabilities discovered in Microsoft Teams, a lack of permission enforcement and attachment spoofing, allow for the GIFShell stager to be convincingly dropped and executed on the victim's machine, completing the attack chain from victim compromise to covert communications. These two vulnerabilities can also lead to RCE directly via a crafted NTLM Relay attack.
This entire attack chain and related vulnerabilities, were reported to Microsoft in May and June of 2022, however after 85 days of review, the reports did not meet their “bar for immediate servicing” despite this being “great research”.
The reports were submitted for Teams — Version 1.5.00.11163 (And Earlier). These vulnerabilities and misconfigurations remain unpatched in the most recent version of Teams and the GIFShell attack chain can be carried on the most recent versions of Teams. Initial research reveals several malware samples which are potentially leveraging this attack chain in the wild. Microsoft has explicitly granted me permission to “blog about/discuss this case and/or present your findings publicly”.
Oftentimes, companies and engineering teams make design decisions based on “assumed risk”, whereby a potentially low impact vulnerability is left unpatched or a security feature is disabled by default, in order to achieve some business objective. I believe this research is demonstrative of an instance where a series of design decisions and “assumed risks” made by a product engineering team, can be chained together into a more pernicious attack chain, and a far higher risk exploit than the product designers imagined was possible.
During the last twenty years Microsoft heavily invested in Windows OS security: both in exploit mitigations, security by design and enforcing security boundaries. Protected Process (PP) and its lightweight cousin, Protected Process Light (PPL), have increased their field of application and are nowadays actively used across various sectors (e.g., DRM and EDR protection, to “shield” main OS functionalities).
As a result, PP/PPL bypasses have also become a hot topic in the industry. This talk will provide a comprehensive overview of the security model and security issues affecting the underlying technology, including past and novel vulnerabilities as well as attack vectors.
As part of the presentation, we will discuss the implementation of PP/PPL processes. The security model of PP/PPL processes will be used to demonstrate each aspect of discovered security vulnerabilities, together with recommendations and mitigations.
A special focus will be on subverting and bending the technology to our will in order to disarm or counter EDR products. While the topic of PP/PPL processes has been shared before at major security conferences in the past, this talk will extend these aspects to include Early Launch AntiMalware (ELAM) and reverse engineering/debugging protected processes.
DSE, KDP and Everything In Between: New Techniques to Run Unsigned Rootkits
Code Integrity is a threat protection feature first introduced by Microsoft over 15 years ago. On x64-based versions of Windows, kernel drivers must be digitally signed and checked each time they are loaded into memory. This is also referred to as Driver Signature Enforcement (DSE).
To overcome this restriction, attackers use valid digital certificates, either issued to them or they stole, or disable DSE during runtime instead. Obtaining a certificate is a logistical obstacle but tampering on the other hand is a technical challenge. Recent years prove the latter tactic only grew in popularity by various APTs as they continued to leverage the well-known DSE tampering technique.
Meanwhile, Microsoft rolled out new mitigations: driver blocklists and Kernel Data Protection (KDP), a new platform security technology for preventing data-oriented attacks. Since using blocklist only narrows the attack vector, we focused on how KDP was applied in this case to eliminate the attack surface.
We'll present two novel techniques we found to bypass KDP-protected DSE. Furthermore, they work on all Windows versions, starting with the first release of DSE. Each technique will be demonstrated on live machines. We'll also suggest a mitigation to cope with the issue, building upon the same premises as attackers, until HVCI becomes prevalent and really eliminates this attack surface.
Two words can make any defender cringe when they hear them: Cobalt Strike. A popular exploit kit used by red teamers, ransomware attackers, and state-nexus actors alike, Cobalt Strike has become the “tool of choice” for many adversaries. Once entry is gained in a network, Cobalt Strike allows an attacker to exploit, move laterally, and compromise accounts and systems, all via relatively stealthy techniques.
However, Cobalt Strike may not be as stealthy as many think. It has telltale signs that, if caught, can stop an adversary in their tracks. In this talk, we will review ways to detect this popular exploit kit, using deep technical analysis of both host- and network-based artifacts. Using what we know about Cobalt Strike's behavior, we'll analyze how to:
- Detect process manipulation
- Uncover privilege escalation and account abuse
- Find lateral movement between systems via host artifacts and network traffic.
Attendees of this talk will gain insight to effectively detect the use of this exploit kit within their environment. However, despite its popularity, Cobalt Strike's use of techniques is not exclusive - in this talk, we'll learn how to detect all types of adversarial activity. Our analysis takeaways will even include preventative countermeasures that can be implemented today. Even better - red teamers who join will learn how their actions are detected and perhaps find new ways to remain stealthy in their target networks!
Connected devices are part of our daily lives: TVs, home routers, IP cameras, voice assistants, air conditioners, and even our cars are now connected to the Internet, and may often represent an attractive target for attackers.
This talk will walk you through our bug hunting approach, showcasing some interesting security vulnerabilities we found and how attackers can actually exploit them to access the target.
The first part of the talk will focus on some “awesome” real cases found via software analysis and reverse engineering, when security experts found high impact vulnerabilities on Automotive components, Smart Home devices and consumer electronic products by looking at the binary code running inside these devices (no source code required!).
The second part will present some real-world hardware attacks, where hot-air stations, solder irons and logic analyzers (and sometimes even circular saws..) are used for gaining privileged access to embedded devices through hardware-based means.