This document discusses attacking the Linux pseudo-random number generator (PRNG) on Android and embedded devices. It begins by motivating the attack by describing a previous vulnerability discovered in the Android keystore. It then provides an overview of the Linux PRNG and describes how an attacker could reconstruct the PRNG's internal state by simulating PRNGs with different seeds and comparing to leaked values from the real PRNG. It discusses problems with mounting the attack and where leaks could be obtained, such as during the kernel or platform boot process. It then describes a local attack method using a malware to obtain a PRNG seed and bypass stack canary protection.
For the Greater Good: Leveraging VMware's RPC Interface for fun and profit by...CODE BLUE
Virtual machines play a crucial role in modern computing. They often are used to isolate multiple customers with instances on the same physical server. Virtual machines are also used by researchers and security practitioners to isolate potentially harmful code for analysis and review. The assumption being made is that by running in a virtual machine, the potentially harmful code cannot execute anywhere else. However, this is not foolproof, as a vulnerability in the virtual machine hypervisor can give access to the entire system. While this was once thought of as just hypothetical, two separate demonstrations at Pwn2Own 2017 proved this exact scenario.
This talk details the host-to-guest communications within VMware. Additionally, the presentation covers the functionalities of the RPC interface. In this section of the presentation, we discuss the techniques that can be used to record or sniff the RPC requests sent from the Guest OS to the Host OS automatically. We also demonstrate how to write tools to query the RPC Interface in C++ and Python for fuzzing purposes.
Finally, we demonstrate how to exploit Use-After-Free vulnerabilities in VMware by walking through a patched vulnerability.
Take a Jailbreak -Stunning Guards for iOS Jailbreak- by Kaoru OtsukaCODE BLUE
In this talk, I investigate several exploiting ideas for iOS kernel jailbreak using recently exposed vulnerabilities. Recently, Ian Beer found the following promising vulnerabilities:
CVE-2016-7637: Broken kernel mach port name ‘uref’ handling on iOS/MacOS can lead to privileged port name replacement in other processes,
CVE-2016-7644: XNU kernel UaF due to lack of locking in set_dp_control_port,
CVE-2016-7661: MacOS/iOS arbitrary port replacement in powerd.
However, naive combination of the above vulnerabilities cannot easily break recent mitigations implemented in iOS versions. Recent iOS provides the kernel level mitigations against exploitation such as kernel patch protection, sandboxing, AMFI(Apple Mobile File Integrity), MAC(Mandatory Access Control) policy, KASLR(Kernel ASLR) etc. These mitigations will be briefly explained.
Recently our team researched various ntos subsystem attack vectors, and one of the outputs we will present in our talk. DeathNote as our internal code name to this component, which resides in Microsoft Windows kernel, hiding behind different interfaces and exposed to user differently.
What can goes bad with it?
Basically two kinds of problems, one is syscall handling via direct user interaction. We will describe how to obtain basic understanding of what's going on, how it interacts with other components and what is its purpose. With those knowledge we will dig deeper how to make more complex fuzzing logic to cause enough chaos that will end up in unexpected behaviors in Windows kernel, and demonstrate some of them.
And as for second, as it hints from title, this module does bit of data parsing, so we will dive deep into internals, pointing out some available materials, and move on to reverse engineered structures and internal mechanism. We will show how some tricks can outcome with various results, and how structured approach can expose more problems than is expected.
Ведущий: Александр Попов
В настоящем докладе будет рассмотрен успешный опыт использования отладочного механизма KASan (Kernel address sanitizer) для автономного гипервизора. Докладчик расскажет, как удалось усилить KASan по сравнению с его реализацией в ядре Linux.
For the Greater Good: Leveraging VMware's RPC Interface for fun and profit by...CODE BLUE
Virtual machines play a crucial role in modern computing. They often are used to isolate multiple customers with instances on the same physical server. Virtual machines are also used by researchers and security practitioners to isolate potentially harmful code for analysis and review. The assumption being made is that by running in a virtual machine, the potentially harmful code cannot execute anywhere else. However, this is not foolproof, as a vulnerability in the virtual machine hypervisor can give access to the entire system. While this was once thought of as just hypothetical, two separate demonstrations at Pwn2Own 2017 proved this exact scenario.
This talk details the host-to-guest communications within VMware. Additionally, the presentation covers the functionalities of the RPC interface. In this section of the presentation, we discuss the techniques that can be used to record or sniff the RPC requests sent from the Guest OS to the Host OS automatically. We also demonstrate how to write tools to query the RPC Interface in C++ and Python for fuzzing purposes.
Finally, we demonstrate how to exploit Use-After-Free vulnerabilities in VMware by walking through a patched vulnerability.
Take a Jailbreak -Stunning Guards for iOS Jailbreak- by Kaoru OtsukaCODE BLUE
In this talk, I investigate several exploiting ideas for iOS kernel jailbreak using recently exposed vulnerabilities. Recently, Ian Beer found the following promising vulnerabilities:
CVE-2016-7637: Broken kernel mach port name ‘uref’ handling on iOS/MacOS can lead to privileged port name replacement in other processes,
CVE-2016-7644: XNU kernel UaF due to lack of locking in set_dp_control_port,
CVE-2016-7661: MacOS/iOS arbitrary port replacement in powerd.
However, naive combination of the above vulnerabilities cannot easily break recent mitigations implemented in iOS versions. Recent iOS provides the kernel level mitigations against exploitation such as kernel patch protection, sandboxing, AMFI(Apple Mobile File Integrity), MAC(Mandatory Access Control) policy, KASLR(Kernel ASLR) etc. These mitigations will be briefly explained.
Recently our team researched various ntos subsystem attack vectors, and one of the outputs we will present in our talk. DeathNote as our internal code name to this component, which resides in Microsoft Windows kernel, hiding behind different interfaces and exposed to user differently.
What can goes bad with it?
Basically two kinds of problems, one is syscall handling via direct user interaction. We will describe how to obtain basic understanding of what's going on, how it interacts with other components and what is its purpose. With those knowledge we will dig deeper how to make more complex fuzzing logic to cause enough chaos that will end up in unexpected behaviors in Windows kernel, and demonstrate some of them.
And as for second, as it hints from title, this module does bit of data parsing, so we will dive deep into internals, pointing out some available materials, and move on to reverse engineered structures and internal mechanism. We will show how some tricks can outcome with various results, and how structured approach can expose more problems than is expected.
Ведущий: Александр Попов
В настоящем докладе будет рассмотрен успешный опыт использования отладочного механизма KASan (Kernel address sanitizer) для автономного гипервизора. Докладчик расскажет, как удалось усилить KASan по сравнению с его реализацией в ядре Linux.
syzbot and the tale of million kernel bugsDmitry Vyukov
The root cause of most software exploits is bugs. Hardening, mitigations and containers are important, but they can't protect a system with thousands of bugs. In this presentation, Dmitry Vyukov will review the current [sad] situation with Linux kernel bugs and security implications based on their experience testing kernel for the past 3 years; overview a set of bug finding tools they are developing (syzbot, syzkaller, KASAN, KMSAN, KTSAN); and discuss problems and areas that require community help to improve the situation.
Zero bugs found? Hold my beer AFL! how to improve coverage-guided fuzzing and...Maksim Shudrak
Fuzzing remains to be the most effective technique for bugs hunting in memory-unsafe programs. Last year, hundreds of security papers and talks on fuzzing have been published and dozens of them were focused on adapting or improving American Fuzzy Lop in some way. Attracting with its simplicity and efficiency, AFL is the number one choice for the vast majority of security researchers. This high popularity means that hunting for bugs with AFL or a similar tool is becoming less and less fruitful since many projects are already covered by other researchers. It is especially hard when we talk about a project participating in Google OSS-Fuzz program which utilizes AFL to generate a half-trillion test cases per day.
In practice, this means that we can not blindly rely on AFL anymore and should search for better fuzzing techniques. In order to overcome this challenge, we need to understand how AFL and similar fuzzers work and be able to use their weaknesses to find new 0days. This talk is aimed to discuss these weaknesses on real examples, explain how we can do fuzzing better and release a new open-source fuzzer called Manul.
Manul is a high-scalable coverage-guided parallel fuzzer with the ability to search for bugs in open source and black box binaries on Windows and Linux. Manul was able to find 10 0-days in 4 widely-used projects that have been extensively tested by AFL. These vulnerabilities were not found by chance, but by analyzing and addressing issues exist in AFL. Authors will show several of the most critical vulnerabilities and explain why AFL overlooked them.
This talk will be interested for experienced hackers, who are willing to improve their bug hunting capabilities, as well as for new researchers, who are making their first steps on the thorny trail of bug hunting.
john-devkit: 100 типов хешей спустя / john-devkit: 100 Hash Types LaterPositive Hack Days
Ведущий: Алексей Черепанов
Скорость взлома хешей растет. Растет и количество алгоритмов хеширования. Объем задач для поддержки универсального инструмента для взлома тоже увеличивается. В ответ на это был разработан john-devkit — улучшенный генератор кода к известному приложению для взлома паролей John the Ripper. john-devkit содержит более 100 типов хешей. Ведущий рассмотрит ключевые аспекты его использования: разделение алгоритмов, оптимизация и вывод данных для различных устройств, простое промежуточное представление алгоритмов хеширования, трудности оптимизации для человека и машины, bitslicing, сравнение скорости обработки.
Introduction to Memory Exploitation (CppEurope 2021)Patricia Aas
Stack based exploitation has gotten all the fame, but many platform and compiler mitigations have made it very hard to exploit stack vulnerabilities. Heap based exploits are still very relevant, and since this is black magic for most developers I will here give an introduction to the field.
Chromium Sandbox on Linux (BlackHoodie 2018)Patricia Aas
The Linux Security and Isolation APIs have become the basis of some of the most useful features server-side, providing the isolation required for efficient containers. However, these APIs also form the basis of the Chromium Sandbox on Linux, and we will study them in that context in this talk.
Ведущий: Иван Ёлкин
Ведущий фаст-трека расскажет об опыте внедрения Static Analysis Security Tool в QIWI, о сложностях, с которыми сталкивались разработчики. Писать «костыли» или рефакторить код? Что делать, когда мнения клиента и разработчика расходятся? Поведает, сколько строк кода пришлось прочитать и написать до и после запуска сканера, и предложит краткий обзор найденных и упущенных уязвимостей.
Ricardo J. Rodríguez & Daniel Uroz - When ROP meets Turing: Automatic Generat...RootedCON
Return-Oriented Programming (ROP) attacks allow to hijack the control-flow execution of a vulnerable process using instructions already present in its memory map. Thus, the attacker concatenates sequences of instructions (named ROP gadgets) redirecting the control-flow execution to perform whatever computation he/she wants. Those instruction sequences, when executed, perform a well-defined operation, such as a XOR or an addition between two registers.
A Turing machine is an abstract concept to define a theoretical model able to solve any computational problem using a set of minimal operations. A system is said to be Turing-complete whether simulates a Turing machine, that is, if it is able to perform the same set of minimal operations. In particular, these operations are: to load a constant, to move values, to load and to store a value from/to memory, and to perform arithmetic and logic operations.
In this talk, we introduce a tool named EasyROP, which seeks the gadgets in a given binary file that are semantically equivalent to each of those operations. Hence, EasyROP helps to automate the development of ROP attacks. We analyzed the main dynamic-link libraries of most flavours of Windows OS, in 32 and 64-bit modes, to study the feasibility of an attack on these systems. We found that shell32.dll is the best candidate in 32-bit systems. In the case of 64-bit systems, none DLL allows to build a Turing machine. We also show the applicability with a real case study, showing how to build a ROP chain attack for CVE-2010-3333 in a Windows 7 32-bit system.
Specializing the Data Path - Hooking into the Linux Network StackKernel TLV
Ever needed to add your custom logic into the network stack?
Ever hacked the network stack but wasn't certain you're doing it right?
Shmulik Ladkani talks about various mechanisms for customizing packet processing logic to the network stack's data path.
He covers covering topics such as packet sockets, netfilter hooks, traffic control actions and ebpf. We will discuss their applicable use-cases, advantages and disadvantages.
Shmulik Ladkani is a Tech Lead at Ravello Systems.
Shmulik started his career at Jungo (acquired by NDS/Cisco) implementing residential gateway software, focusing on embedded Linux, Linux kernel, networking and hardware/software integration.
51966 coffees and billions of forwarded packets later, with millions of homes running his software, Shmulik left his position as Jungo’s lead architect and joined Ravello Systems (acquired by Oracle) as tech lead, developing a virtual data center as a cloud service. He's now focused around virtualization systems, network virtualization and SDN.
One Shellcode to Rule Them All: Cross-Platform ExploitationQuinn Wilton
As the internet of things becomes less a buzzword, and more a reality, we're noticing that it's growing increasingly common to see embedded software which runs across different architectures -whether that's the same router firmware running across different models, or the operating system for a smart TV being used by different manufacturers. In a world where even your toaster might have internet access, we suspect that the ability to write cross-platform shellcode is going transition from being a merely neat trick, to a viable tool for attackers.
Writing cross-platform shellcode is tough, but there's a few techniques you can use to simplify the problem. We discuss one such method, which we used to great success during the DEFCON CTF qualifiers this year.
Presented by Tinfoil Security founder Michael Borohovski and engineer Shane Wilton at Secuinside 2014, in Seoul.
https://www.tinfoilsecurity.com/blog/cross-platform-exploitation
Kernel Recipes 2014 - Writing Code: Keep It Short, Stupid!Anne Nicolas
The traditional KISS principle says that you are stupid if you can’t keep it simple. However, keeping it simple is actually very, very hard. But my lasting impression after reading a lot of code (linux kernel and otherwise) over the years is that there is no excuse for not keeping your code short. And usually, keeping it short is a very good first step towards keeping it simple. This presentation will give some simple tricks and pointers to keep your code short and I will also give some guidelines how to do design and implementation from a high-level point of view. These simple rules should make it easier for you to get your code accepted in open source projects such as the linux kernel.
Hans Verkuil
[CB17] Trueseeing: Effective Dataflow Analysis over Dalvik OpcodesCODE BLUE
Trueseeing is an automatic vulnerability scanner for Android apps. It is capable of not only directly conducting data flow analysis over Dalvik bytecode but also automatically fixing the code, i.e. without any decompilers. This capability makes it resillent against basic obfuscations and distinguishes it among similar tools -- including the QARK, the scanner/explotation tool shown by Linkedin in DEF CON 23. Currently it recognizes the most class of vulnerabilities (as in OWASP Mobile Top 10 (2015).) We have presented it in DEF CON 25 Demo Labs. Our tool is at: https://github.com/monolithworks/trueseeing.
Takahiro Yoshimura
TAKAHIRO YOSHIMURA: He is Chief Technology Officer at Monolith Works Inc. In 2012 METI-coodinated CTF, Challenge CTF Japan 2012, his team (Enemy10) had won local qualification round at the 1st prize. In 2013, his team (Sutegoma2) took the 6th prize in DEFCON 21 CTF. He like to read binaries and hack things. He loves a GSD.
https://keybase.io/alterakey
Ken-ya Yoshimura
KEN-YA YOSHIMURA: Working as Chief Executive Officer at Monolith Works Inc, he is supervising an R&D lab specializing in emerging technologies. His hacker life starts when he was 8 years old; he likes to hack MSXs, NEC PC-9800s, Sharp X68000s, Windows, Macs, iPhones, iOS/Android apps, and circumvent copyright protection (for fun,) etc. He adores a GSD.
https://keybase.io/ad3liae
All about the Linux boot process. Presented at linux.conf.au on January 25, 2018. Video at https://archive.org/details/lca2018-Linux_the_first_second . Associated blog posting at https://opensource.com/article/18/1/analyzing-linux-boot-process
PowerShell Inside Out: Applied .NET Hacking for Enhanced Visibility by Satosh...CODE BLUE
In response to the emerging use of PowerShell by attackers, Microsoft released a feature called Anti-Malware Scan Interface (AMSI) in Windows 10, allowing 3rd party companies, as well as Microsoft itself, to gain more visibility into PowerShell and other scripting engines. Since this release, various research has been done on the effectiveness of AMSI, revealing its efficacy as well as its inherent weaknesses.
Despite this advance, however, many security vendors have yet to add AMSI support in their products, perhaps due to its limited platform coverage. On the other hand, red teamers and adversaries have quickly equipped themselves with techniques which attack the weaknesses of AMSI and bypass it, making detection and prevention of PowerShell attacks even harder.
This talk will discuss how to gain greater visibility into managed program execution, especially for PowerShell, using a .NET native code hooking technique to help organizations protect themselves from such advanced attacker techniques. In this session, we will demonstrate how to enhance capabilities provided by AMSI and how to overcome its limitations, through a realistic implementation of the technique, all while analyzing the internals of .NET Framework and the PowerShell engine.
-> Deep dive inside the kernel Interrupt management subsystem.
-> Entire presentation is oriented towards 8259 Interrupt controller.
-> Detail understanding of how request_irq() function works.
syzbot and the tale of million kernel bugsDmitry Vyukov
The root cause of most software exploits is bugs. Hardening, mitigations and containers are important, but they can't protect a system with thousands of bugs. In this presentation, Dmitry Vyukov will review the current [sad] situation with Linux kernel bugs and security implications based on their experience testing kernel for the past 3 years; overview a set of bug finding tools they are developing (syzbot, syzkaller, KASAN, KMSAN, KTSAN); and discuss problems and areas that require community help to improve the situation.
Zero bugs found? Hold my beer AFL! how to improve coverage-guided fuzzing and...Maksim Shudrak
Fuzzing remains to be the most effective technique for bugs hunting in memory-unsafe programs. Last year, hundreds of security papers and talks on fuzzing have been published and dozens of them were focused on adapting or improving American Fuzzy Lop in some way. Attracting with its simplicity and efficiency, AFL is the number one choice for the vast majority of security researchers. This high popularity means that hunting for bugs with AFL or a similar tool is becoming less and less fruitful since many projects are already covered by other researchers. It is especially hard when we talk about a project participating in Google OSS-Fuzz program which utilizes AFL to generate a half-trillion test cases per day.
In practice, this means that we can not blindly rely on AFL anymore and should search for better fuzzing techniques. In order to overcome this challenge, we need to understand how AFL and similar fuzzers work and be able to use their weaknesses to find new 0days. This talk is aimed to discuss these weaknesses on real examples, explain how we can do fuzzing better and release a new open-source fuzzer called Manul.
Manul is a high-scalable coverage-guided parallel fuzzer with the ability to search for bugs in open source and black box binaries on Windows and Linux. Manul was able to find 10 0-days in 4 widely-used projects that have been extensively tested by AFL. These vulnerabilities were not found by chance, but by analyzing and addressing issues exist in AFL. Authors will show several of the most critical vulnerabilities and explain why AFL overlooked them.
This talk will be interested for experienced hackers, who are willing to improve their bug hunting capabilities, as well as for new researchers, who are making their first steps on the thorny trail of bug hunting.
john-devkit: 100 типов хешей спустя / john-devkit: 100 Hash Types LaterPositive Hack Days
Ведущий: Алексей Черепанов
Скорость взлома хешей растет. Растет и количество алгоритмов хеширования. Объем задач для поддержки универсального инструмента для взлома тоже увеличивается. В ответ на это был разработан john-devkit — улучшенный генератор кода к известному приложению для взлома паролей John the Ripper. john-devkit содержит более 100 типов хешей. Ведущий рассмотрит ключевые аспекты его использования: разделение алгоритмов, оптимизация и вывод данных для различных устройств, простое промежуточное представление алгоритмов хеширования, трудности оптимизации для человека и машины, bitslicing, сравнение скорости обработки.
Introduction to Memory Exploitation (CppEurope 2021)Patricia Aas
Stack based exploitation has gotten all the fame, but many platform and compiler mitigations have made it very hard to exploit stack vulnerabilities. Heap based exploits are still very relevant, and since this is black magic for most developers I will here give an introduction to the field.
Chromium Sandbox on Linux (BlackHoodie 2018)Patricia Aas
The Linux Security and Isolation APIs have become the basis of some of the most useful features server-side, providing the isolation required for efficient containers. However, these APIs also form the basis of the Chromium Sandbox on Linux, and we will study them in that context in this talk.
Ведущий: Иван Ёлкин
Ведущий фаст-трека расскажет об опыте внедрения Static Analysis Security Tool в QIWI, о сложностях, с которыми сталкивались разработчики. Писать «костыли» или рефакторить код? Что делать, когда мнения клиента и разработчика расходятся? Поведает, сколько строк кода пришлось прочитать и написать до и после запуска сканера, и предложит краткий обзор найденных и упущенных уязвимостей.
Ricardo J. Rodríguez & Daniel Uroz - When ROP meets Turing: Automatic Generat...RootedCON
Return-Oriented Programming (ROP) attacks allow to hijack the control-flow execution of a vulnerable process using instructions already present in its memory map. Thus, the attacker concatenates sequences of instructions (named ROP gadgets) redirecting the control-flow execution to perform whatever computation he/she wants. Those instruction sequences, when executed, perform a well-defined operation, such as a XOR or an addition between two registers.
A Turing machine is an abstract concept to define a theoretical model able to solve any computational problem using a set of minimal operations. A system is said to be Turing-complete whether simulates a Turing machine, that is, if it is able to perform the same set of minimal operations. In particular, these operations are: to load a constant, to move values, to load and to store a value from/to memory, and to perform arithmetic and logic operations.
In this talk, we introduce a tool named EasyROP, which seeks the gadgets in a given binary file that are semantically equivalent to each of those operations. Hence, EasyROP helps to automate the development of ROP attacks. We analyzed the main dynamic-link libraries of most flavours of Windows OS, in 32 and 64-bit modes, to study the feasibility of an attack on these systems. We found that shell32.dll is the best candidate in 32-bit systems. In the case of 64-bit systems, none DLL allows to build a Turing machine. We also show the applicability with a real case study, showing how to build a ROP chain attack for CVE-2010-3333 in a Windows 7 32-bit system.
Specializing the Data Path - Hooking into the Linux Network StackKernel TLV
Ever needed to add your custom logic into the network stack?
Ever hacked the network stack but wasn't certain you're doing it right?
Shmulik Ladkani talks about various mechanisms for customizing packet processing logic to the network stack's data path.
He covers covering topics such as packet sockets, netfilter hooks, traffic control actions and ebpf. We will discuss their applicable use-cases, advantages and disadvantages.
Shmulik Ladkani is a Tech Lead at Ravello Systems.
Shmulik started his career at Jungo (acquired by NDS/Cisco) implementing residential gateway software, focusing on embedded Linux, Linux kernel, networking and hardware/software integration.
51966 coffees and billions of forwarded packets later, with millions of homes running his software, Shmulik left his position as Jungo’s lead architect and joined Ravello Systems (acquired by Oracle) as tech lead, developing a virtual data center as a cloud service. He's now focused around virtualization systems, network virtualization and SDN.
One Shellcode to Rule Them All: Cross-Platform ExploitationQuinn Wilton
As the internet of things becomes less a buzzword, and more a reality, we're noticing that it's growing increasingly common to see embedded software which runs across different architectures -whether that's the same router firmware running across different models, or the operating system for a smart TV being used by different manufacturers. In a world where even your toaster might have internet access, we suspect that the ability to write cross-platform shellcode is going transition from being a merely neat trick, to a viable tool for attackers.
Writing cross-platform shellcode is tough, but there's a few techniques you can use to simplify the problem. We discuss one such method, which we used to great success during the DEFCON CTF qualifiers this year.
Presented by Tinfoil Security founder Michael Borohovski and engineer Shane Wilton at Secuinside 2014, in Seoul.
https://www.tinfoilsecurity.com/blog/cross-platform-exploitation
Kernel Recipes 2014 - Writing Code: Keep It Short, Stupid!Anne Nicolas
The traditional KISS principle says that you are stupid if you can’t keep it simple. However, keeping it simple is actually very, very hard. But my lasting impression after reading a lot of code (linux kernel and otherwise) over the years is that there is no excuse for not keeping your code short. And usually, keeping it short is a very good first step towards keeping it simple. This presentation will give some simple tricks and pointers to keep your code short and I will also give some guidelines how to do design and implementation from a high-level point of view. These simple rules should make it easier for you to get your code accepted in open source projects such as the linux kernel.
Hans Verkuil
[CB17] Trueseeing: Effective Dataflow Analysis over Dalvik OpcodesCODE BLUE
Trueseeing is an automatic vulnerability scanner for Android apps. It is capable of not only directly conducting data flow analysis over Dalvik bytecode but also automatically fixing the code, i.e. without any decompilers. This capability makes it resillent against basic obfuscations and distinguishes it among similar tools -- including the QARK, the scanner/explotation tool shown by Linkedin in DEF CON 23. Currently it recognizes the most class of vulnerabilities (as in OWASP Mobile Top 10 (2015).) We have presented it in DEF CON 25 Demo Labs. Our tool is at: https://github.com/monolithworks/trueseeing.
Takahiro Yoshimura
TAKAHIRO YOSHIMURA: He is Chief Technology Officer at Monolith Works Inc. In 2012 METI-coodinated CTF, Challenge CTF Japan 2012, his team (Enemy10) had won local qualification round at the 1st prize. In 2013, his team (Sutegoma2) took the 6th prize in DEFCON 21 CTF. He like to read binaries and hack things. He loves a GSD.
https://keybase.io/alterakey
Ken-ya Yoshimura
KEN-YA YOSHIMURA: Working as Chief Executive Officer at Monolith Works Inc, he is supervising an R&D lab specializing in emerging technologies. His hacker life starts when he was 8 years old; he likes to hack MSXs, NEC PC-9800s, Sharp X68000s, Windows, Macs, iPhones, iOS/Android apps, and circumvent copyright protection (for fun,) etc. He adores a GSD.
https://keybase.io/ad3liae
All about the Linux boot process. Presented at linux.conf.au on January 25, 2018. Video at https://archive.org/details/lca2018-Linux_the_first_second . Associated blog posting at https://opensource.com/article/18/1/analyzing-linux-boot-process
PowerShell Inside Out: Applied .NET Hacking for Enhanced Visibility by Satosh...CODE BLUE
In response to the emerging use of PowerShell by attackers, Microsoft released a feature called Anti-Malware Scan Interface (AMSI) in Windows 10, allowing 3rd party companies, as well as Microsoft itself, to gain more visibility into PowerShell and other scripting engines. Since this release, various research has been done on the effectiveness of AMSI, revealing its efficacy as well as its inherent weaknesses.
Despite this advance, however, many security vendors have yet to add AMSI support in their products, perhaps due to its limited platform coverage. On the other hand, red teamers and adversaries have quickly equipped themselves with techniques which attack the weaknesses of AMSI and bypass it, making detection and prevention of PowerShell attacks even harder.
This talk will discuss how to gain greater visibility into managed program execution, especially for PowerShell, using a .NET native code hooking technique to help organizations protect themselves from such advanced attacker techniques. In this session, we will demonstrate how to enhance capabilities provided by AMSI and how to overcome its limitations, through a realistic implementation of the technique, all while analyzing the internals of .NET Framework and the PowerShell engine.
-> Deep dive inside the kernel Interrupt management subsystem.
-> Entire presentation is oriented towards 8259 Interrupt controller.
-> Detail understanding of how request_irq() function works.
Practical IoT Exploitation (DEFCON23 IoTVillage) - Lyon YangLyon Yang
This is a light training/presentation talk.
My name is Lyon Yang and I am an IoT hacker. I live in sunny Singapore where IoT is rapidly being deployed – in production. This walkthrough will aim to shed light on the subject of IoT, from finding vulnerabilities in IoT devices to getting shiny hash prompts.
Our journey starts with a holistic view of IoT security, the issues faced by IoT devices and the common mistakes made by IoT developers. Things will then get technical as we progress into a both ARM and MIPS exploitation, followed by a ‘hack-along-with-us’ workshop where you will be exploiting a commonly found IoT daemon. If you are new to IoT or a seasoned professional you will likely learn something new in this workshop.
https://www.iotvillage.org/#schedule
[Usenix's WOOT'14] Attacking the Linux PRNG and Android - Weaknesses in Seedi...srkedmi
Android is the most prevalent Linux-based mobile Operating System in the market today. Many features of the platform security (such as stack protection, key generation, etc.) are based on values provided by the Linux Pseudorandom Number Generator (LPRNG) and weaknesses in the LPRNG could therefore directly affect platform security. Much literature has been published previously investigating and detailing such weaknesses in the LPRNG. We build upon this prior work and show that - given a leak of a random value extracted from the LPRNG - a practical, inexpensive attack against the LPRNG internal state in early boot is feasible. Furthermore, the version of the Linux kernel vulnerable to such an attack is used in the majority of Android-based mobile devices in circulation. We also present two real-world exploitation vectors that could be enabled by such an attack. Finally, we mention current mitigations and highlight lessons that can be learned in respect to the design and use of future PRNGs for security features on embedded platforms.
TENTACLE: Environment-Sensitive Malware Palpation(PacSec 2014)FFRI, Inc.
In this presentation, I present an automatically disarmament system for armed malware with anti-sandboxing. The system targets on 1) Host-fingerprinting malware like citadel, 2) armed malware with general anti-sandboxng for automated sandbox analyzer. An approach of disarmament focuses on exit reason and exit before activity in malware execution. I have developing CPU emulator-based disarmament system with instrumentation. The system suggests a suitable environment for dynamic analysis for individual malware.
Smash the Stack: Writing a Buffer Overflow Exploit (Win32)Elvin Gentiles
Slides from my ROOTCON12 training. This material contains an introduction to stack-based buffer overflow. This is also helpful for those who are doing OSCP and wanted to learn exploit development.
We show that it is possible to write remote stack buffer overflow exploits without possessing a copy of the target binary or source code, against services that restart after a crash. This makes it possible to hack proprietary closed-binary services, or open-source servers manually compiled and installed from source where the binary remains unknown to the attacker. Traditional techniques are usually paired against a particular binary and distribution where the hacker knows the location of useful gadgets for Return Oriented Programming (ROP). Our Blind ROP (BROP) attack instead remotely finds enough ROP gadgets to perform a write system call and transfers the vulnerable binary over the network, after which an exploit can be completed using known techniques. This is accomplished by leaking a single bit of information based on whether a process crashed or not when given a particular input string. BROP requires a stack vulnerability and a service that restarts after a crash. The attack works against modern 64-bit Linux with address space layout randomization (ASLR), no-execute page protection (NX) and stack canaries.
We show that it is possible to write remote stack buffer overflow exploits without possessing a copy of the target binary or source code, against services that restart after a crash. This makes it possible to hack proprietary closed-binary services, or open-source servers manually compiled and installed from source where the binary remains unknown to the attacker. Traditional techniques are usually paired against a particular binary and distribution where the hacker knows the location of useful gadgets for Return Oriented Programming (ROP). Our Blind ROP (BROP) attack instead remotely finds enough ROP gadgets to perform a write system call and transfers the vulnerable binary over the network, after which an exploit can be completed using known techniques. This is accomplished by leaking a single bit of information based on whether a process crashed or not when given a particular input string. BROP requires a stack vulnerability and a service that restarts after a crash. The attack works against modern 64-bit Linux with address space layout randomization (ASLR), no-execute page protection (NX) and stack canaries.
Freeze Drying for Capturing Environment-Sensitive Malware AliveFFRI, Inc.
We propose a set of techniques for "freeze drying" malware and restoring the captured malware to enable live process migration. Our system can capture environment-sensitive malware in-process and run it in an environment other than the infected host.
Sophisticated malware, such as Citadel and ZeuS/GameOver, are armed with anti-analysis techniques to prevent running except on an infected host. These malwares detect the execution environment and do not engage in malicious behavior when the current host differs from the infected host.
We developed a malware capture system called Sweetspot that can capture malware in-process by using process live migration and mimicking the infected host's environment on the analyzer by means of system call proxies. In addition, Sweetspot can serve as a honeypot and provide dummy data when the malware requests sensitive information. In briefings, we will demonstrate freeze-drying and instant dynamic analysis of real malware.
Protocol T50: Five months later... So what?Nelson Brito
T50 (an Experimental Mixed Packet Injector) new features added to version 5.3 (Chaos Maker).
Check the original demonstration videos:
- https://www.youtube.com/playlist?list=PLda9TmFadx_m2qdd-euUf4zhQ-5juTVEx
For further source codes, please, refer to:
- http://t50.sourceforge.net/
Agenda:
This talk will provide an in-depth review of the usage of canaries in the kernel and the interaction with userspace, as well as a short review of canaries and why they are needed in general so don't be afraid if you never heard of them.
Speaker:
Gil Yankovitch, CEO, Chief Security Researcher from Nyx Security Solutions
The research work that I describe in this dissertation is concerned with
the problem of shared-memory synchronization in large-scale
programs.
The difficulties of developing fine-grained lock-based synchronization
are well-known and many researchers have argued for the need of
alternative approaches.
Simply put, the main goal of my work is to provide an efficient
alternative to such approaches.
My proposal is based on Software Transactional Memory
(STM) and I implemented it in a well-known STM framework for
Java---Deuce STM.
To that end I propose a new approach that significantly lowers the
overhead caused by an STM in large-scale programs for which only a
small fraction of the memory is under contention. My solution
combines two novel optimization techniques in a synergistic way,
allowing us to get, for the first time, performance with an STM that
rivals the performance of the best lock-based approaches in some of
the more challenging benchmarks. My approach and experimental
results show that STMs may be the first efficient alternative to locks
for shared-memory synchronization in real-world--sized applications.
You're Off the Hook: Blinding Security SoftwareCylance
User-mode hooking is dead. It’s also considered harmful due to interference with OS-level exploit mitigations like Control Flow Guard (CFG). At BlackHat US 2016, the “Captain Hook” talk revealed there were multiple serious security issues in AV hooking — we will put the final nail in the coffin by showing how trivial it is to bypass user-mode hooks. We will demonstrate a universal user-mode unhooking approach that can be included in any binary to blind security software from monitoring code execution and perform heuristic analysis. The tool and source code will be released on GitHub after the talk.
Alex Matrosov | Principal Research Scientist
Jeff Tang | Senior Security Researcher
Generating a custom Ruby SDK for your web service or Rails API using Smithyg2nightmarescribd
Have you ever wanted a Ruby client API to communicate with your web service? Smithy is a protocol-agnostic language for defining services and SDKs. Smithy Ruby is an implementation of Smithy that generates a Ruby SDK using a Smithy model. In this talk, we will explore Smithy and Smithy Ruby to learn how to generate custom feature-rich SDKs that can communicate with any web service, such as a Rails JSON API.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
6. motivation_keystore_buffer_overflow
• We discovered CVE-2014-3100, a stack-based Buffer
Overflow in Keystore
• Service responsible for securely storing crypto related data
• We had privately reported to Google and they provided a
patch available in KITKAT. Whitepaper.
• Exploit must overcome various defense mechanisms, including
Stack Canaries.
/* KeyStore is a secured storage for key-value pairs. In this implementation,
* each file stores one key-value pair. Keys are encoded in file names, and
* values are encrypted with checksums. The encryption key is protected by a
* user-defined password. To keep things simple, buffers are always larger than
* the maximum space we needed, so boundary checks on buffers are omitted. */
7. motivation_keystore_buffer_overflow
Stack canaries and their enforcement
LR
Saved
Registers
Canary
(32 bits)
Buffer
Stack
layout
Linux PRNG
AUXV(AT_RANDOM)
__stack_chk_guard
Stack Guard
initialization
32 bits
128
bits
• On libbionic load:
__stack_chk_guard = *(uintptr_t *)getauxval(AT_RANDOM));
• Function Prologue:
● Place __stack_chk_guard on the stack (before ret).
• Function Epilogue:
● Compare saved stack canary with __stack_chk_guard;
→ Crash if mismatch
8. motivation_keystore_buffer_overflow
Stack canaries and their enforcement
LR
Saved
Registers
Canary
(32 bits)
Buffer
Stack
layout
Linux PRNG
AUXV(AT_RANDOM)
__stack_chk_guard
Stack Guard
initialization
32 bits
128
bits
• On libbionic load:
__stack_chk_guard = *(uintptr_t *)getauxval(AT_RANDOM));
• Function Prologue:
● Place __stack_chk_guard on the stack (before ret).
• Function Epilogue:
● Compare saved stack canary with __stack_chk_guard;
→ Crash if mismatch
● fork() → execve().
● execve() → Auxiliary vector (AUXV)
● AUXV[AT_RANDOM] = 16 Random bytes from the PRNG
● libbionic assigns canary = first 4 bytes of AT_RANDOM
Canary origins; *nix process creation model
9. motivation_keystore_buffer_overflow
Stack canaries and their enforcement
LR
Saved
Registers
Canary
(32 bits)
Buffer
Stack
layout
Linux PRNG
AUXV(AT_RANDOM)
__stack_chk_guard
Stack Guard
initialization
32 bits
128
bits
• On libbionic load:
__stack_chk_guard = *(uintptr_t *)getauxval(AT_RANDOM));
• Function Prologue:
● Place __stack_chk_guard on the stack (before ret).
• Function Epilogue:
● Compare saved stack canary with __stack_chk_guard;
→ Crash if mismatch
● fork() → execve().
● execve() → Auxiliary vector (AUXV)
● AUXV[AT_RANDOM] = 16 Random bytes from the PRNG
● libbionic assigns canary = first 4 bytes of AT_RANDOM
Canary origins; *nix process creation model
Remember this; We'll get back to it
12. motivation_keystore_buffer_overflow
LR
Saved
Registers
Canary
(32 bits)
Buffer
Stack
layout
Linux PRNG
AUXV(AT_RANDOM)
Stack Guard
initialization
32 bits
128
bits
__stack_chk_guard
Attacks on the Stack-Smashing Protection:
• Naive Online Bruteforce of the Canary Value
• Impractical: 2^32 attempts on average.
• Online Learning of the Canary Value
• By another info leak issue
• Re-forking server:
• Very efficient: 514 attempts until
success on average
• Overwrite __stack_chk_guard
• By overwriting some pointer
13. motivation_keystore_buffer_overflow
LR
Saved
Registers
Canary
(32 bits)
Buffer
Attacks on the Stack-Smashing Protection:
• Naive Online Bruteforce of the Canary Value
• Impractical: 2^32 attempts on average.
• Online Learning of the Canary Value
• By another info leak issue
• Re-forking server:
• Very efficient: 514 attempts until
success on average
• Overwrite __stack_chk_guard
• By overwriting some pointer
• Our attack: Offline reconstruction of the
PRNG’s internal state
Stack
layout
Linux PRNG
AUXV(AT_RANDOM)
Stack Guard
initialization
32 bits
128
bits
__stack_chk_guard__stack_chk_guard__stack_chk_guard
14. motivation_wrap_up
LR
Saved
Registers
Canary
(32 bits)
Buffer
Wrap things up:
• We found a vulnerability in a critical service
in Android 4.3.
• In an effort to exploit it, we had to overcome
a stack canary, we couldn't do so using
known techniques.
• Canaries are 4 random bytes that are
extracted from the Linux PRNG.
• Aimed to find a weakness in the PRNG that
will allow us to intelligently guess the canary.
• End up with a full-fledged attack on the Linux
PRNG.
Stack
layout
Linux PRNG
AUXV(AT_RANDOM)
Stack Guard
initialization
32 bits
128
bits
__stack_chk_guard__stack_chk_guard__stack_chk_guard
16. INPUT POOL
BLOCKING POOL
NON-BLOCKING POOL
/dev/urandom
/dev/random
get_random_bytes()
lprng_overview
Bird's eye view
• Output is hashed twice using SHA1
• Extracts in blocks of 10 bytes and truncates if necessary.
17. INPUT POOL NON-BLOCKING-POOL
ktime_t ktime_t
EXTRACTION (PULL)
INTERRUPT
DISK
INPUT
T
I
M
E
R
time
if KEC >= 192 bits
*KEC = Kernel Entropy Count
entropy_sources
63 31 0
seconds nanoseconds
18. INPUT POOL NON-BLOCKING-POOL
ktime_t ktime_t
EXTRACTION (PULL)
INTERRUPT
DISK
INPUT
T
I
M
E
R
time
if KEC < 192 bits
*KEC = Kernel Entropy Count
boot_time_vulnerability
63 31 0
seconds nanoseconds
22. Prior art on weakness in early boot *
Present practical run-time attack
Formalize attack
Demonstrate PoC against current mobile platforms
contribution
* Heninger et al. 2012, Becherer et al. 2009, Ding et al. 2014
23. Given a LEAK of a value extracted from the non-blocking pool and
LOW ENTROPY AT BOOT, the STATE of the PRNG can be
determined until external entropy is too high
attack_outcome
24. NON-BLOCKING-POOL
seed_t1
EXTRACTION (PULL)
63 31 0
seconds nseconds
Using the PRNG against itself
●
Recall: Low boot-time entropy degenerates
the PRNG and that the output of the PRNG is
hashed twice using SHA1.
●
Fact: Crypto. hash functions are designed to
be collision resistant.
attack_leak
NON-BLOCKING-POOL
EXTRACTION (PULL)
≠
seed_t2
seed_t1
63 31 0
seconds nseconds
25. NON-BLOCKING-POOL
seed_t1
EXTRACTION (PULL)
63 31 0
seconds nseconds
Using the PRNG against itself
●
Recall: Low boot-time entropy degenerates
the PRNG and that the output of the PRNG is
hashed twice using SHA1.
●
Fact: Crypto. hash functions are designed to
be collision resistant.
●
It is highly unlikely that PRNGs that are
seeded with different seeds will result in the
same output. Regardless of the order of
extractions.
attack_leak
NON-BLOCKING-POOL
EXTRACTION (PULL)
≠
seed_t2
seed_t1
63 31 0
seconds nseconds
26. NON-BLOCKING-POOL
seed_t1
EXTRACTION (PULL)
63 31 0
seconds nseconds
Using the PRNG against itself
●
Recall: Low boot-time entropy degenerates
the PRNG and that the output of the PRNG is
hashed twice using SHA1.
●
Fact: Crypto. hash functions are designed to
be collision resistant.
●
It is highly unlikely that PRNGs that are
seeded with different seeds will result in the
same output. Regardless of the order of
extractions.
●
Result: Every leak(sequence of random
bytes) from the non blocking pool is almost
certainly the offspring of one specific seed.
attack_leak
NON-BLOCKING-POOL
EXTRACTION (PULL)
≠
seed_t2
seed_t1
63 31 0
seconds nseconds
27. Using the PRNG against itself
●
Given a leak from the nonblocking pool of a
“Real” PRNG we could simulate offline PRNGs
with different seeds and compare extractions
with the online leak.
attack_overview
REAL
PRNG
= LEAK ?
seed_t_k
LEAK
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
SIM.
PRNG
seed_t_k
RANDOM VALUE
28. Using the PRNG against itself
●
Given a leak from the nonblocking pool of a
“Real” PRNG we could simulate offline PRNGs
with different seeds and compare extractions
with the online leak.
●
Due to SHA1's collision resistance, if one of
the simulated PRNGs produces a sequence of
random bytes that is the same as the leak
value – we almost certainly found the seed.
attack_overview
REAL
PRNG
= LEAK ?
seed_t_k
LEAK
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
SIM.
PRNG
seed_t_k
RANDOM VALUE
29. Using the PRNG against itself
●
Given a leak from the nonblocking pool of a
“Real” PRNG we could simulate offline PRNGs
with different seeds and compare extractions
with the online leak.
●
Due to SHA1's collision resistance, if one of
the simulated PRNGs produces a sequence of
random bytes that is the same as the leak
value – we almost certainly found the seed.
●
Once we have the seed we can produce the
same outputs of the “Real” PRNG until noise
from the Input pool is mixed to the
Nonblocking pool
attack_overview
REAL
PRNG
= LEAK ?
seed_t_k
LEAK
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
SIM.
PRNG
seed_t_k
RANDOM VALUE
30. Even After the mixing, the PRNG is vulnerable
●
Note: in the whitepaper we demonstrated a
more intricate attack flow
attack_overview
REAL
PRNG
= LEAK ?
seed_t_k
LEAK
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
SIM.
PRNG
seed_t_k
RANDOM VALUE
31. Problems we faced:
●
The Nonblocking pool seed is 8 bytes long,
Say we consider only the nanoseconds and
assuming uniform distribution
attack_overview
10
9
=2
log2
(10
9
)
≃2
30
63 31 0
seconds nanoseconds
REAL
PRNG
= LEAK ?
seed_t_k
LEAK
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
SIM.
PRNG
seed_t_k
RANDOM VALUE
32. Problems we faced:
●
The Nonblocking pool seed is 8 bytes long,
Say we consider only the nanoseconds and
assuming uniform distribution
●
Hidden entropy source – Concurrency
attack_overview
10
9
=2
log2
(10
9
)
≃2
30
REAL
PRNG
= LEAK ?
seed_t_k
LEAK
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
SIM.
PRNG
seed_t_k
RANDOM VALUE
1
2
3
4
3
4
POOL
STATE
Yellow Path
- Process A: extract from pool
- Process A: mix into pool
- Process B: extract from pool
- Process B: mix into pool
Green Path
- Process A: extract from pool
- Process B: extract from pool
- Process A: mix into pool
- Process B: mix into pool
33. Problems we faced:
●
The Nonblocking pool seed is 8 bytes long,
Say we consider only the nanoseconds and
assuming uniform distribution
●
Hidden entropy source – Concurrency
●
What can be attacked?
●
Where can we get the leak value?
attack_overview
10
9
=2
log2
(10
9
)
≃2
30
REAL
PRNG
= LEAK ?
seed_t_k
LEAK
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
SIM.
PRNG
seed_t_k
RANDOM VALUE
34. Where can we find leaks and attack targets ?
attack_overview
Kernel
starts booting
PRNG is
initialized
Kernel boot
Finished &
Platform starts
booting
Input Pool mixed
into Nonblocking
Pool :(
Phone is
ready
Concurrency Hell
Best
Leak/Target
Good
Leak/Target
Bad
Leak/Target
Device
powers on
35. Terminology
attack_overview
Device
powers on
Kernel
starts booting
PRNG is
initialized
Kernel boot
Finished &
Platform starts
booting
Input Pool mixed
into Nonblocking
Pool :(
Phone is
ready
Kernel
Boot-time
Leak/Target
Platform
Boot-time
Leak/Target
Concurrency Hell
Best
Leak/Target
Good
Leak/Target
Bad
Leak/Target
38. Instrumenting a device
●
Samsung Galaxy S4, Android 4.3
●
printk() input and nonblocking pool seeds -
find a bias in the seed value
●
printk() get_random_bytes() callers and
amount of random bytes requested – find
leak and attack targets
s4_offline_study
39. Instrumenting a device
●
Samsung Galaxy S4, Android 4.3
●
printk() input and nonblocking pool seeds -
find a bias in the seed value
●
printk() get_random_bytes() callers and
amount of random bytes requested – find
leak and attack targets
●
Fixed the seeds to see catch some bias in
the order of extractions – find bias in conc.
s4_offline_study
40. Instrumenting a device
●
Samsung Galaxy S4, Android 4.3
●
printk() input and nonblocking pool seeds -
find a bias in the seed value
●
printk() get_random_bytes() callers and
amount of random bytes requested – find
leak and attack targets
●
Fixed the seeds to see catch some bias in
the order of extractions – find bias in conc.
●
In total, we rebooted(script) the device more
than 2000 times, each time we dumped the
kernel ring buffer to a file.
s4_offline_study
42. Details
●
Android designers chose to spawn every app
process by forking a master process – Zygote
s4_attack_leak
REAL
PRNG
= LEAK ?
seed_t_k
LEAK
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
leak/target
43. Details
●
Android designers chose to spawn every app
process by forking a master process – Zygote
●
Zygote(app_process) is fork'ed and exec'ed by
init at platform boot-time
s4_attack_leak
REAL
PRNG
= LEAK ?
seed_t_k
LEAK
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
leak/target
44. Details
●
Android designers chose to spawn every app
process by forking a master process – Zygote
●
Zygote(app_process) is fork'ed and exec'ed by
init at platform boot-time
●
*nix-like vs. App process creation model.
Exec() ?
s4_attack_leak
REAL
PRNG
= LEAK ?
seed_t_k
LEAK
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
leak/target
45. Details
●
Android designers chose to spawn every app
process by forking a master process – Zygote
●
Zygote(app_process) is fork'ed and exec'ed by
init at platform boot-time
●
*nix-like vs. App process creation model.
Exec() ?
●
Recall: exec() enforces ASLR and assigns the
AT_RANDOM
s4_attack_leak
REAL
PRNG
= LEAK ?
seed_t_k
LEAK
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
leak/target
46. Details
●
Result: All Applications in Android has the
same Canary value (AT_RANDOM) and largely
the same address space layout
s4_attack_leak
REAL
PRNG
= LEAK ?
seed_t_k
LEAK
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
fork()
AUXV(AT_RANDOM)
Zygote Linux PRNG
AUXV(AT_RANDOM) – Zygote's
WhatsApp
AUXV(AT_RANDOM) – Zygote's
Contacts
AUXV(AT_RANDOM) – Zygote's
MALWARE
fork()
leak/target
47. Details
●
Result: All Applications in Android has the
same Canary value (AT_RANDOM) and largely
the same address space layout
s4_attack_leak
REAL
PRNG
= LEAK ?
seed_t_k
LEAK
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
fork()
AUXV(AT_RANDOM)
Zygote Linux PRNG
AUXV(AT_RANDOM) – Zygote's
WhatsApp
AUXV(AT_RANDOM) – Zygote's
Contacts
AUXV(AT_RANDOM) – Zygote's
MALWARE
fork() fork()
leak/target
49. s4_attack_leak_concurrency
REAL
PRNG
= LEAK ?
seed_t_k
LEAK
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
Given a leak, what's the probability of
finding the original seed ?
●
Zygote's AT_RANDOM is our leak
It's a platform boot-time leak, which means It
occurs in the 'Concurrency Hell' phase
●
An offline study of the samples revealed bias
towards a specific extraction path from the
nonblocking pool
leak/target
50. s4_attack_leak_concurrency
REAL
PRNG
= LEAK ?
seed_t_k
LEAK
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
Given a leak, what's the probability of
finding the original seed ?
●
Zygote's AT_RANDOM is our leak
It's a platform boot-time leak, which means It
occurs in the 'Concurrency Hell' phase
●
An offline study of the samples revealed bias
towards a specific extraction path from the
nonblocking pool
●
20% of the samples had Zygote's AT_RANDOM
bytes somewhere in the extraction path
leak/target
53. = LEAK ?
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
SIM.
PRNG
seed_t_k
RANDOM VALUE
s4_attack_targets
leak/target
Given a seed, Probabilities of finding
the canary of early boot services
54. = LEAK ?
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
Given a seed, Probabilities of finding
the canary of early boot services
SIM.
PRNG
seed_t_k
RANDOM VALUE
s4_attack_targets
leak/target
6
100
55. = LEAK ?
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
Given Zygote's AT_RANDOM, the
probability of guessing the Keystore's
canary value is:
SIM.
PRNG
seed_t_k
RANDOM VALUE
s4_attack_targets
leak/target
1
5
⋅
6
100
≃0.01→1%
Remember where we came from...
we needed to guess 32 random bits
56. = LEAK ?
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
Given Zygote's AT_RANDOM, the
probability of guessing the Keystore's
canary value is:
SIM.
PRNG
seed_t_k
RANDOM VALUE
s4_attack_targets
leak/target
1
5
⋅
6
100
≃0.01→1%
1
232
≃0.00000000023→0.000000023%
60. Instrumenting a device
●
Samsung Galaxy S2, Android 4.1.2
●
printk() input and nonblocking pool seeds -
find a bias in the seed value
●
printk() get_random_bytes() callers and
amount of random bytes requested – find
leak and attack targets
s2_offline_study
61. Instrumenting a device
●
Samsung Galaxy S2, Android 4.1.2
●
printk() input and nonblocking pool seeds -
find a bias in the seed value
●
printk() get_random_bytes() callers and
amount of random bytes requested – find
leak and attack targets
●
Fixed the seeds to see catch some bias in
the order of extractions – find bias in conc.
s2_offline_study
62. Instrumenting a device
●
Samsung Galaxy S2, Android 4.1.2
●
printk() input and nonblocking pool seeds -
find a bias in the seed value
●
printk() get_random_bytes() callers and
amount of random bytes requested – find
leak and attack targets
●
Fixed the seeds to see catch some bias in
the order of extractions – find bias in conc.
●
In total, we rebooted(script) the device more
than 2000 times, each time we dumped the
kernel ring buffer to a file.
s2_offline_study
64. Details
●
While the kernel is brought up, an IPv6 module
initializes and extracts 4 random bytes. Lets
call them rand.
s2_attack_leak
REAL
PRNG
= LEAK ?
seed_t_k
LEAK
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
leak/target
65. Details
●
While the kernel is brought up, an IPv6 module
initializes and extracts 4 random bytes. Lets
call them rand.
●
IPv6 packet fragment identifier is computed by
a deterministic function.
s2_attack_leak
REAL
PRNG
= LEAK ?
seed_t_k
LEAK
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
leak/target
f(rand, ipv6_dst_addr)=ipv6_frag_id
66. Details
●
While the kernel is brought up, an IPv6 module
initializes and extracts 4 random bytes. Lets
call them rand.
●
IPv6 packet fragment identifier is computed by
a deterministic function.
●
The pair (ipv6_dst_addr,ipv6_frag_id) is our leak.
Why?
s2_attack_leak
REAL
PRNG
= LEAK ?
seed_t_k
LEAK
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
leak/target
f(rand, ipv6_dst_addr)=ipv6_frag_id
67. Details
●
While the kernel is brought up, an IPv6 module
initializes and extracts 4 random bytes. Lets
call them rand.
●
IPv6 packet fragment identifier is computed by
a deterministic function.
●
The pair (ipv6_dst_addr,ipv6_frag_id) is our leak.
Why?
●
We simulate PRNGs up to rand, and feed it to
the deterministic function f
s2_attack_leak
REAL
PRNG
= ipv6_frag_id ?
seed_t_k
LEAK
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
rand_t_1 rand_t_k
f(rnd,dst) f(rnd,dst) f(rnd,dst)
rand_t_n
leak/target
f(rand, ipv6_dst_addr)=ipv6_frag_id
68. Details
●
While the kernel is brought up, an IPv6 module
initializes and extracts 4 random bytes. Lets
call them rand.
●
IPv6 packet fragment identifier is computed by
a deterministic function.
●
The pair (ipv6_dst_addr,ipv6_frag_id) is our leak.
Why?
●
We simulate PRNGs up to rand, and feed it to
the deterministic function f
●
OK, fine, but how did you get ipv6_dst_addr?
s2_attack_leak
REAL
PRNG
= ipv6_frag_id ?
seed_t_k
LEAK
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
rand_t_1 rand_t_k
f(rnd,dst) f(rnd,dst) f(rnd,dst)
rand_t_n
leak/target
f(rand, ipv6_dst_addr)=ipv6_frag_id
69. IPv6 fragmentation & ICMPv6 Echo Req.
●
IP packets that exceed the path MTU, are
divided into fragments which are sent and
then reassembled by receiver.
s2_attack_leak
leak/target
70. IPv6 fragmentation & ICMPv6 Echo Req.
●
IP packets that exceed the path MTU, are
divided into fragments which are sent and
then reassembled by receiver.
●
Each fragment of the packet contains the
same fragment id. Which is used by the
receiver to identify fragments of a packet.
s2_attack_leak
leak/target
71. IPv6 fragmentation & ICMPv6 Echo Req.
●
IP packets that exceed the path MTU, are
divided into fragments which are sent and
then reassembled by receiver.
●
Each fragment of the packet contains the
same fragment id. Which is used by the
receiver to identify fragments of a packet.
●
IPv6 fragmentation doesn't happen very
often. How do we make it happen ?
s2_attack_leak
leak/target
72. IPv6 fragmentation & ICMPv6 Echo Req.
●
Ping6 – a utility for sending ICMPv6 Echo
Requests which requires the target to
send an ICMPv6 Echo Replay with the
exactly the same data.
s2_attack_leak
leak/target
73. IPv6 fragmentation & ICMPv6 Echo Req.
●
Ping6 – a utility for sending ICMPv6 Echo
Requests which requires the target to
send an ICMPv6 Echo Replay with the
exactly the same data.
●
Result: Sending ICMPv6 Echo Request
with data > MTU will make the receiver
send a fragmented reply
s2_attack_leak
leak/target
83. s2_attack_targets
REAL
PRNG
= ipv6_frag_id ?
seed_t_k
LEAK
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
rand_t_1 rand_t_k
f(rnd,dst) f(rnd,dst) f(rnd,dst)
rand_t_n
Given the seed what can we attack ?
●
IPv6 Fragment injection – We can derive the
exact fragment id V will use for any destination
address.
●
Canary value of early boot services.
For instance, with a probability of 1/20 we can
compute Keystore's canary value, given the
seed.
targetleak
84. = ipv6_frag_id ?
SIM.
PRNG
seed_t_1
SIM.
PRNG
seed_t_k
SIM .
PRNG
seed_t_n
... ...
rand_t_1 rand_t_k
f(rnd,dst) f(rnd,dst) f(rnd,dst)
rand_t_n
SIM.
PRNG
seed_t_k
RANDOM VALUE
s2_attack_targets
Probabilities of finding the canary
of early boot services
leak target
87. mitigations
Current mitigations
●
Save entropy across boots
●
Trusted external entropy injection –
web service / HWRNG
INPUT POOL NON-BLOCKING-POOL
ktime_t ktime_t
EXTRACTION (PULL)
T
I
M
E
R
INTERRUPT
DISK
INPUT
time
if KEC >= 192 bits
88. mitigations
Problem with those mitigations
Kernel
starts booting
PRNG is
initialized
Kernel boot
Finished &
Platform starts
booting
Input Pool mixed
into Nonblocking
Pool :(
Phone is
ready
Concurrency Hell
Best
Leak/Target
Good
Leak/Target
Bad
Leak/Target
Device
powers on
Injecting
Entropy to
Pools
Entropy
89. mitigations
Problem with those mitigations
Kernel
starts booting
PRNG is
initialized
Kernel boot
Finished &
Platform starts
booting
Input Pool mixed
into Nonblocking
Pool :(
Phone is
ready
Concurrency Hell
Best
Leak/Target
Good
Leak/Target
Bad
Leak/Target
Device
powers on
Kernel
Boot-time
Leak/Target
Injecting
Entropy to
Pools
Entropy
Entropy injection occurs after the
kernel boots up
90. mitigations
Current mitigations
●
Initialize the seeds using a hardware RNG
●
RDRAND,RDSEED Intel's ISA
●
Early random, Qualcomm
INPUT POOL NON-BLOCKING-POOL
ktime_t ktime_t
EXTRACTION (PULL)
T
I
M
E
R
INTERRUPT
DISK
INPUT
time
if KEC >= 192 bits
91. mitigations
Current mitigations
●
Initialize the seeds using a hardware RNG
●
RDRAND,RDSEED Intel's ISA
●
Early random, Qualcomm
●
Mix device-specific data to nonblocking and
blocking pools
INPUT POOL NON-BLOCKING-POOL
ktime_t ktime_t
EXTRACTION (PULL)
T
I
M
E
R
INTERRUPT
DISK
INPUT
time
if KEC >= 192 bits
92. mitigations
Current mitigations
●
Initialize the seeds using a hardware RNG
●
RDRAND,RDSEED Intel's ISA
●
Early random, Qualcomm
●
Mix device-specific data to nonblocking and
blocking pools
●
Changes to newer kernels allow for more
boot time entropy
INPUT POOL NON-BLOCKING-POOL
ktime_t ktime_t
EXTRACTION (PULL)
T
I
M
E
R
INTERRUPT
DISK
INPUT
time
if KEC >= 192 bits
93. talk_wrap_up
• Linux-based devices with low boot time entropy may
allow a practical, low-cost attack on the PRNG
• The attack requires an offline study of a device and an
online leak
• Allows the attacker to predict a random number which is
generated by the victim's PRNG
• Two manifestations - Local/Remote Atk.
• Mitigations