• XSS.stack #1 – первый литературный журнал от юзеров форума

Видео OffensiveCon 2023 - материалы с конференции

weaver

31 c0 bb ea 1b e6 77 66 b8 88 13 50 ff d3
Забанен
Регистрация
19.12.2018
Сообщения
3 301
Решения
11
Реакции
4 622
Депозит
0.0001
Пожалуйста, обратите внимание, что пользователь заблокирован

The Print Spooler Bug that Wasn’t in the Print Spooler​

It all started with a “Print Spooler” 0-day privilege escalation, CVE-2022-41073, on investigation the fix in the spooler was almost trivial. However, based on issues Project Zero has discovered in the past it was clear the real vulnerability was inside the Windows DLL loader. To understand the fix a deeper dive into the internals of the loader and the role CSRSS plays in handling side by side assemblies was necessary, leading to the discovery of a series of not quite complete patches.

This talk takes you through the process of root causing an in-the-wild “Print Spooler” bug: from patch diffing, to finding an exploit sample, to diving into months of changes within Windows DLL loader. The result was identifying a Project Zero bug from 2019 which might have been the first variant of the 2022 vulnerability exploited in the wild.

We’ll give a primer on Windows Activation Contexts and the evolution of bugs in the area. We’ll look into a series of related bugs, going back many years, including three that were known to be actively exploited. We’ll also detail the many iterative fixes that Microsoft deployed that led to so many bugs, making this a prime attack surface. Finally, we’ll go over the new mitigations that Windows added in late 2022 and early 2023.
slides

video
youtube.com/watch?v=H03b0UaogVs&list=PLYvhPWR_XYJmh-qBNKUrlyjQYKBpCDZzB
 
Пожалуйста, обратите внимание, что пользователь заблокирован

Unearthing Vulnerabilities in the Apple Ecosystem: The Art of KidFuzzerV2.0​

In last year's POC, I presented KidFuzzer, which revealed numerous bugs in IOKit Drivers. Following redesign and development, I'm excited to introduce KidFuzzerV2.0, which includes an innovative Driver collection method that could expand driver attack surfaces by 95%. Then I will demonstrate how to do the lateral migration with the "Backward Fuzzing" idea in Apple Kernel space and discuss the bugs found in XNU kernel, IOKit Drivers, and various firmwares, including DCP/SEP/AOP, etc.

This presentation would first do a quick review of the attack surfaces and mitigations in Apple Kernel space as well as my ideas towards future trend. Next, it will discuss the new design and how it extracts abstract patterns from several public and unpublic Apple N-day bugs. The abstract patterns will then be converted to "Backward Fuzzing" and applied to iPhone/SRD/M1/Intel devices, resulting in the discovery of over 50 bugs, including XNU kernel, Apple Drivers, and Co-processor firmwares such as DCP/SEP/AOP. These efforts have already yielded more than ten assigned CVEs, such as CVE-2023-28187/CVE-2023-28186/CVE-2023-28185/CVE-2023-28184/CVE-2023-23502/CVE-2023-23501/CVE-2023-23500/CVE-2022-42854/CVE-2022-42833/CVE-2022-42820/CVE-2022-32916, with others currently in progress.

Additionally, this talk will dive into the details of several unpublic bugs found in XNU/Drivers/Co-processor firmwares and an intriguing flaw pattern in Apple Drivers, which existed for 20 years and resulted in more than 20 kernel infoleak bugs.

slides

video
youtube.com/watch?v=oML1h3ic__0&list=PLYvhPWR_XYJmh-qBNKUrlyjQYKBpCDZzB
 
Пожалуйста, обратите внимание, что пользователь заблокирован

A Dark Side of UEFI: Cross-Silicon Exploitation​

In January 2023 we disclosed multiple vulnerabilities affecting Qualcomm reference code and impacting different device vendors and IBVs (https://binarly.io/posts/Multiple_Vulnerabilities_in_Qualcomm_and_Lenovo_ARM_based_Devices). Usually, UEFI firmware related vulnerabilities are disclosed from the perspective of the x86 ecosystem on Intel or AMD based devices. This is the first public disclosure in history of UEFI specification related to the ARM device ecosystem. It shows some of the attacks and classes of bugs can be the same on both ARM and x86 devices, but exploitation specifics will be different. These vulnerabilities are confirmed on Lenovo’s Thinkpad and Microsoft’s Surface devices during our research. Even the recently released development device Microsoft Windows Dev Kit 2023 (code name “Project Volterra”) is impacted.

These three vulnerabilities BRLY-2022-029, BRLY-2022-030, BRLY-2022-033 have a high-impact CVSS score since they can lead to a secure boot bypass, and enable an attacker to gain persistence on a device by gaining sufficient privileges to write to the file system, thus allowing an attacker to cross an extra security boundary to simplify attacks on TrustZone. All three are impacting Qualcomm’s reference code and affect the entire ecosystem.

The goal of the presentation is to discuss the different aspects of unification of firmware development with frameworks like UEFI and what kind of security implications it can have from the attacker and defender perspectives.

slides

video
youtube.com/watch?v=9dfISRD6hwk&list=PLYvhPWR_XYJmh-qBNKUrlyjQYKBpCDZzB
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Теперь понятно почему Седрик целый год выпуск курса откладывал.
Самое интересное, что все публичные техники эксплуатации в linux уже давно закрыты grsecurity)) нового ничего пока не видно...
 
everything is cool from dumping image --> study bootloader+NVRAM --> cool --> until we get inside end of chain --> he turn out to become a memory corruption+leak --> monkey disappoints(( --> where are logic bugs hiding? --> did qualcomm write such top perfect format specifications?
Cross-Silicon
misleading name --> laughter+chagrin
 
Пожалуйста, обратите внимание, что пользователь заблокирован
misleading name --> laughter+chagrin
these lines reveal the essence of the title.
Usually, UEFI firmware related vulnerabilities are disclosed from the perspective of the x86 ecosystem on Intel or AMD based devices. This is the first public disclosure in history of UEFI specification related to the ARM device ecosystem.
 
these lines reveal the essence of the title.
if someone wants to use such cool name --> "silicon" --> he is for design+logic flaws inside hardware --> not even such ugly firmware + interafaces + bootloaders himself
example --> silicon based covert channel
 
Пожалуйста, обратите внимание, что пользователь заблокирован
UPD: Загрузили видео на ютуб, так же добавил видео к предыдущим постам.
Весь плейлист --> youtube.com/playlist?list=PLYvhPWR_XYJmh-qBNKUrlyjQYKBpCDZzB

Так же хотел добавить в данный тред следующие доклады, но к сожаленью слайдов нету или по крайне мере я их не нашел. Если найду обновлю пост.

MacDirtyCow – Auditing and Exploiting XNU Virtual Memory
I spent a considerable amount of time in 2022 trying to understand the XNU virtual memory subsystem. I definitely still don't understand it, but I did find some fun bugs along the way :) In this talk I'll discuss the story of those bugs, try to explain the the bits of the virtual memory subsystem I now sort-of understand and show how you could use these vulns to do fun stuff.
video
youtube.com/watch?v=jrxOhGGxDZ8&list=PLYvhPWR_XYJmh-qBNKUrlyjQYKBpCDZzB



Abusing Linux In-Kernel SMB Server to Gain Kernel Remote Code Execution
KSMBD is a young component in the Linux kernel upstreamed since 5.15 and shipping with Ubuntu 22.04. It offers an in-kernel SMB server focused on performance, and attempts to keep the complex, non-performance-critical parts of the protocol separate in a userspace daemon. This talk focuses on several vulnerabilities discovered in the KSMBD kernel module itself, which we chained to achieve kernel remote code execution. An exploit against a vulnerable Ubuntu 22.04 server will be performed live.

KSMBD as opposed to Samba mostly runs as a kernel module. It interfaces with the Linux virtual file system to achieve higher performance. Building on top of Samba experience, KSMBD chooses to delegate the handling of user authentication and Remote Procedure Call services to a group of privileged userspace processes, running as root in the default Ubuntu deployment.

During the summer of 2022, several vulnerabilities were uncovered through an audit of both the KSMBD kernel module and userland binaries. Among them, a bunch of various weaknesses, ranging from memory exhaustion to kernel use-after-free, a.k.a the much hyped ZDI-22-1690 / CVE-2022-47939 (rated a perfect CVSS 10.0 by ZDI, CVSS 9.8 by NIST). Those vulnerabilities were reported and patched[.]

Three of those vulnerabilities were chained to achieve kernel remote code execution: ZDI-22-1691, ZDI-22-1688, and ZDI-CAN-18259. Attacking over the network prevents us from reusing known techniques used in a local exploit, where the attacker may execute arbitrary code in userland. However, SMB protocol semantics and implementation helped us build effective remote primitives. Up-to-date kernel mitigations are bypassed and a demo will feature a remote kernel thread hijack ending into a `uid=0` reverse shell.
video
youtube.com/watch?v=XT6jLBbzwFM&list=PLYvhPWR_XYJmh-qBNKUrlyjQYKBpCDZzB



Inside Apple’s Lightning: JTAGging the iPhone for Fuzzing and Profit
If you've been around the iPhone hacking scene you probably heard about the mysterious cables named after different monkeys: Kanzi Cable, Kong Cable, Bonobo Cable - all these cables allow you to get JTAG debugging capabilities on the iPhone, however they are also very difficult to get on the regular market. Last year we released the first open-source iPhone JTAG cable: The Tamarin Cable, a firmware for the Raspberry Pi Pico that allows building a $10 iPhone JTAG adapter.

Since then, we've worked on utilizing Tamarin and Lightning to automate certain tasks for low-level fuzzing of the iPhone.
In this talk we will:
  • Dive into the hardware (Tristar) and protocol (SDQ/IDBUS) details of Lighting
  • Show how we implemented our own SDQ/IDBUS adapter
  • Demonstrate our Lightning-Fuzzer: A fuzzer to find new Lightning commands
  • Dive into implementing SWD for the iPhone and how to use with checkm8ble devices
After this, we will look at using Lightning to implement a low-level fuzzer for the iPhone:
Thanks to some undocumented Lightning commands we can utilize Lightning to quickly (and automatically) reset the iPhone - and get it into DFU mode. This allowed us to build low-level fuzzers for parts of the iPhone that so far very only very difficult to test.

Our fuzzers (and fuzzing results) will be made public with this presentation.
video
youtube.com/watch?v=-nFWcKHIUN4&list=PLYvhPWR_XYJmh-qBNKUrlyjQYKBpCDZzB



What’s in a Name? (sbx chrome ipc)
In late 2022, Chrome fixed an anonymously reported vulnerability in the Mojo IPC implementation, noting that there was an exploit for this vulnerability in the wild. The details of the report have not been made public, and as a Chrome sandbox-escape connoisseur I feel this bug deserves a bit more love - so in this talk I'll give a full explanation of the bug (and the context around it), and then briefly discuss the exploitation primitives that it provided.
video
youtube.com/watch?v=rX8kfeksdi4&list=PLYvhPWR_XYJmh-qBNKUrlyjQYKBpCDZzB



Your Mitigations Are My Opportunities
Every modern Windows mitigation can be bypassed. Mitigations can have unintentional bugs, design choices that create known gaps, or just good old backwards compatibility. And while these protections may succeed in killing older exploit primitives, they also sometimes introduce entirely new ones. This talk will provide a whirlwind tour through exploitation on a modern Windows system and introduce advanced techniques for the modern attacker.

The first half of this talk will focus on some of the newer Windows mitigations, like XFG, CET, KCET, HVCI and others, and explain how they prevent and mitigate classic exploitation techniques. Then we’ll see how we can build a ROP-based exploit that will work on the most recent Windows 11 systems through a new type confusion technique.

Once we achieve code execution on the machine, we’ll turn our attention to EDRs. As EDRs advance and become more advanced, the potential attack surface against them grows as well. We’ll examine Windows Defender, which currently runs seven drivers and multiple processes, making it an interesting potential attack surface. We’ll see how all this code provides new opportunities to an attacker, for example through a secret “debug mode”, new available devices and hookable kernel interfaces that allow a kernel-level attacker to hide where neither the OS nor the EDR itself will notice.
slides
video
youtube.com/watch?v=YnxGW8Fvqvk&list=PLYvhPWR_XYJmh-qBNKUrlyjQYKBpCDZzB



Advancements in JavaScript Engine Fuzzing
What’s new in JavaScript engine fuzzing, and what might still be to come? This talk will dive into the unique challenges and opportunities of JavaScript engine fuzzing. For example, while the bugs typically found in modern JavaScript engines often require complex interactions to trigger, the nature of JavaScript also makes it possible to use features like runtime introspection to generate smarter testcases. Various new fuzzing techniques specifically for dynamic language interpreters will be discussed and have been implemented in the open-source fuzzer Fuzzilli. Along the way, some noteworthy bugs will also be presented.

Fuzzing dynamic language interpreters such as JavaScript engines remains an interesting research topic. This talk will discuss recent advancements in Fuzzilli, an open-source JavaScript engine fuzzer that has found hundreds of bugs in widely-used Javascript engines such as V8, the engine powering Google Chrome.

After a brief introduction of Fuzzilli and its basic functionality, this talk will discuss some novel mutators that have recently been added to Fuzzilli and which all make use of the dynamic nature of JavaScript, in particular its ability for runtime introspection, to generate smarter testcases. Further, the talk will show how using custom runtime feedback can also improve generative, not just mutation-based, fuzzing.

Along the way, some noteworthy bugs found by Fuzzilli in the recent past will be presented, and contrasted to some bug types, such as concurrency related issues, that remain hard to find through fuzzing. The talk closes by looking at possible future advancements in Fuzzilli specifically and dynamic language fuzzing in general.
slides

video
youtube.com/watch?v=Yd9m7e9-pG0&list=PLYvhPWR_XYJmh-qBNKUrlyjQYKBpCDZzB
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Однако, однако - векторы атак остаются теми же. Да и ошибки даже одинаковые, достаточно посмотреть на армовскую прошку и обычную под x86
Согласен архитектура не слишком уж то и отличается, пробуют различные векторы атак и разные техники эксплуатации, если оно работает вводят аналогичные митигейшены которые уже есть на x86_x64. а так все тоже самое.
 


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх