This document discusses exploiting the OS X El Capitan kernel using a vulnerability found in IOAcceleratorFamily. It describes how memory spraying can be used to leak kernel information despite mitigations like kASLR. It then provides a case study of exploiting CVE-2016-1815, an out-of-bounds write bug, to leak bytes from kernel memory and eventually gain kernel code execution. The exploitation technique involves spraying kernel memory with controlled data, overwriting a function pointer to point to that data, and using an information leak primitive to read bytes from the sprayed region and bypass kASLR.
Poc2015 os x_kernel_is_as_strong_as_its_weakest_part_liang_shuaitianLiang Chen
With the popularity of Apple's system, many OS X kernel vulnerabilities were discovered by fuzzing IOKit. OS X kernel exploitation technology has developed in the past few years, yet recent Apple patches have mitigated most of those technology to avoid generic address leak as well as zone Feng Shui approaches, which, as a result, make harder to exploit OS X kernel vulnerabilities.
In the first part of this talk, we will show several vulnerabilities discovered by KeenTeam whose details have never been published before. Then we conclude about several root causes to Apple IOKit driver's weakness, and how to take advantage of those weakness to find bugs more efficiently.
The second part will cover how to exploit a vulnerability in such case, and how to pave a road from crash to root with the presence of Apple’s new mitigation.
Poc2015 os x_kernel_is_as_strong_as_its_weakest_part_liang_shuaitianLiang Chen
With the popularity of Apple's system, many OS X kernel vulnerabilities were discovered by fuzzing IOKit. OS X kernel exploitation technology has developed in the past few years, yet recent Apple patches have mitigated most of those technology to avoid generic address leak as well as zone Feng Shui approaches, which, as a result, make harder to exploit OS X kernel vulnerabilities.
In the first part of this talk, we will show several vulnerabilities discovered by KeenTeam whose details have never been published before. Then we conclude about several root causes to Apple IOKit driver's weakness, and how to take advantage of those weakness to find bugs more efficiently.
The second part will cover how to exploit a vulnerability in such case, and how to pave a road from crash to root with the presence of Apple’s new mitigation.
Windows Kernel Exploitation : This Time Font hunt you down in 4 bytesPeter Hlavaty
In our recent work we targeted also win32k, what seems to be fruit giving target. @promised_lu made our own TTF-fuzzer which comes with bunch of results in form of gigabytes of crashes and various bugs. Fortunately windows make great work and in February most of our bugs was dead - patched, but not all of them…
Whats left were looking as seemingly unexploitable kernel bugs with ridiculous conditions. We decided to check it out, and finally combine it with our user mode bug & emet bypass. Through IE & flash we break down system and pointed out at weak points in defensive mechanism.
In this talk we will present our research dedicated for pwn2own event this year. We will describe kernel part of exploit in detail*, including bug description, resulting memory corruption conditions & caveats up to final pwn via one of our TTF bugs.
Throughout the talk we will describe how to break various exploit mitigations in windows kernel and why it is possible. We will introduce novel kernel exploitation techniques breaking all what stands { KASLR, SMEP, even imaginary SMAP or CFG } and bring you SYSTEM exec (from kernel driver to system calc).
* unfortunately bug was not fixed at the time of talk, so we do not exposed details about TTF vulnerability, and we skipped directly to some challenges during exploitation, and demonstrate how OS design can overpower introduced exploit mitigations.
Injection on Steroids: Codeless code injection and 0-day techniquesenSilo
Most nefarious activities carried out by malware—such as running code in Internet Explorer in an attempt to steal passwords, hijack sessions, or conduct Man-in-the-Browser fraud, require code injection.
This session exposes additional new user- and kernel-mode injection techniques. One of these techniques we’ve coined as “code-less code injection” since, as opposed to other known injection techniques, does not require adding code to the injected process.
Security research over Windows #defcon chinaPeter Hlavaty
Past several years Microsoft Windows undergo lot of fundamental security changes. Where one can argue still imperfect and bound to tons of legacy issues, on the other hand those changes made important shifts in attacker perspective. From tightened sandboxing, restricting attack surface, introducing mitigations, applying virtualization up to stronger focus even on win32k. In our talk we will go trough those changes, how it affects us and how we tackle them from choosing targets, finding bugs up to exploitation primitives we are using. While also empathize that windows research is not only about sandbox, and there are many more interesting target to look for.
Kernel vulnerabilities was commonly used to obtain admin privileges, and main rule was to stay in kernel as small time as possible! But nowdays even when you get admin / root then current operating systems are sometimes too restrictive. And that made kernel exploitation nice vector for installing to kernel mode!
In this talk we will examine steps from CPL3 to CPL0, including some nice tricks, and we end up with developing kernel mode drivers.
As computer systems become more sophisticated, process injection techniques also evolve. These techniques are notorious for their use by "malicious software" to hide code execution and avoid detection. In this presentation we dive deep into the Windows runtime and we demonstrate these techniques. Besides, we also learn how to code construction and design patterns that relate to perform hidden code can recognize.
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.
Pressetation about how to find vulnerabilities and do reversing to the iOS Operating System. The author is Steffan Esser and the talk was delivered in SyScan 2011 in Singapur
Captain Hook: Pirating AVs to Bypass Exploit MitigationsenSilo
In this talk we reveal six(!) different security issues that we uncovered in various hooking engines. The vulnerabilities we found enable a threat actor to bypass the security measures of the underlying operating system. As we uncovered the vulnerabilities one-by-one we found them to impact commercial engines, such as Microsoft’s Detours, open source engines such as EasyHook and proprietary engines such as those belonging to TrendMicro, Symantec, Kaspersky and about twenty others.
Steelcon 2014 - Process Injection with Pythoninfodox
This is the slides to accompany the talk given by Darren Martyn at the Steelcon security conference in July 2014 about process injection using python.
Covers using Python to manipulate processes by injecting code on x86, x86_64, and ARMv7l platforms, and writing a stager that automatically detects what platform it is running on and intelligently decides which shellcode to inject, and via which method.
The Proof of Concept code is available at https://github.com/infodox/steelcon-python-injection
50 Shades of Fuzzing by Peter Hlavaty & Marco GrassiShakacon
Graphic drivers and their related code are an essential component in every modern operating system. This particular component involves especially complex logic and a huge amount of code, simply because it must handle equally complex tasks.
As we know from history and experience huge and complex code is often also a security risk. Last but not least, in almost all the popular modern operating system, graphics code and logic is running in a highly privileged context such as the kernel, or even in a higher context, such as VMWare graphics component, which essentially implements your graphic card outside the guest into a host process.
Any mistake made into this highly privileged code can lead to a fatal outcome, especially considering that it is often reachable from interesting sandboxes, such as the browser ones. We will go through the internals for various graphic systems, to show similarities and differences, such as windows heart of graphics aka win32k, then OSX/iOS IOKit, and finally, WMWare emulated GPU graphic subsystem. We can then switch gear and showcase some vulnerabilities in these scenarios, discuss effective fuzzing methodologies both specific to a particular target and generic principles of fuzzing graphic subsystems as well.
This talk will cover how powerfull are buffer overflows, how weak are mitigations against them, why are buffer overflows still possible in those days, how generic are they, and example how useful is turn race conditions to buffer overflow. Race conditions are nice example for that, because they are one of the hardest to find and on of the easiest to make. example is on Linux kernel (droids included), but talk will be keeped for buffer overflows in general (mainly for windows & Linux kernel)
Surviving the Java Deserialization Apocalypse // OWASP AppSecEU 2016Christian Schneider
The hidden danger of Java deserialization vulnerabilities – which often lead to remote code execution – has gained extended visibility in the past year. The issue has been known for years; however, it seems that the majority of developers were unaware of it until recent media coverage around commonly used libraries and major products. This talk aims to shed some light about how this vulnerability can be abused, how to detect it from a static and dynamic point of view, and -- most importantly -- how to effectively protect against it. The scope of this talk is not limited to the Java serialization protocol but also other popular Java libraries used for object serialization.
The ever-increasing number of new vulnerable endpoints and attacker-usable gadgets has resulted in a lot of different recommendations on how to protect your applications, including look-ahead deserialization and runtime agents to monitor and protect the deserialization process. Coming at the problem from a developer’s perspective and triaging the recommendations for you, this talk will review existing protection techniques and demonstrate their effectiveness on real applications. It will also review existing techniques and present new gadgets that demonstrates how attackers can actually abuse your application code and classpath to craft a chain of gadgets that will allow them to compromise your servers.
This talk will also present the typical architectural decisions and code patterns that lead to an increased risk of exposing deserialization vulnerabilities. Mapping the typical anti-patterns that must be avoided, through the use of real code examples we present an overview of hardening techniques and their effectiveness. The talk will also show attendees what to search the code for in order to find potential code gadgets the attackers can leverage to compromise their applications. We’ll conclude with action items and recommendations developers should consider to mitigate this threat.
--
This talk was presented by Alvaro Muñoz & Christian Schneider at the OWASP AppSecEU 2016 conference in Rome.
Serial Killer - Silently Pwning your Java Endpoints // OWASP BeNeLux Day 2016Christian Schneider
In this session we begin with modelling the attack surface of Java deserialization, which often leads to remote code execution (RCE), by showcasing vulnerabilities we found in modern and widely used applications and frameworks. We extend existing research about risks of deserialization broadening the attack surface. After a live demo of getting a Meterpreter shell in a modern Java endpoint setup we delve into the exploitation styles for this vulnerability to lay the foundation of the first of three key takeaways for the attendees:
The first key takeaway is identification of test types that should be executed during a dynamic assessment of an application in order to find this kind of vulnerability. This includes analyzing the deserialization interface and using blackbox tests to create payloads with gadgets matching the application’s classpath to verify the RCE. Discussion extends to cover indirect deserialization interfaces that use non-binary data formats, such as XML-based interfaces, which can also act as a driver for deserialization within the application.
The next key takeaway covers the realm of static code analysis (SAST). We present code patterns security reviewers should look for when doing whitebox assessments of applications or frameworks. This is especially interesting for code offering dynamic functionality including AOP, generic mappings, reflection, interceptors, etc. - all of which have a high probability of including code that can facilitate as deserialization gadgets and thus help the attackers in exploiting deserialization vulnerabilities. In this section we present the techniques used to find the vulnerabilities within the popular frameworks showcased during the live demo at the session’s start.
Finally we conclude with tips on implementing different techniques of hardening measures for applications offering deserialisation interfaces (either direct binary deserialization interfaces or indirect XML-based ones) to give the attendees the third key takeaway: protecting applications properly. This includes ways to verify data integrity prior to deserialization and ways to properly inspect the data before it’s handled by the Java deserialization process.
--
This talk was presented by Christian Schneider & Alvaro Muñoz at the OWASP BeNeLux Day 2016.
As @nicowaisman mentioned in his talk Aleatory Persistent Threat, old school heap specific exploiting is dying. And with each windows SP or new version, is harder to attack heap itself. Heap management adapt quickly and include new mittigation techniques. But sometimes is better to rethink the idea of mittigation and do this technique properly even half version of it will cover all known heap exploit techniques…
Windows Kernel Exploitation : This Time Font hunt you down in 4 bytesPeter Hlavaty
In our recent work we targeted also win32k, what seems to be fruit giving target. @promised_lu made our own TTF-fuzzer which comes with bunch of results in form of gigabytes of crashes and various bugs. Fortunately windows make great work and in February most of our bugs was dead - patched, but not all of them…
Whats left were looking as seemingly unexploitable kernel bugs with ridiculous conditions. We decided to check it out, and finally combine it with our user mode bug & emet bypass. Through IE & flash we break down system and pointed out at weak points in defensive mechanism.
In this talk we will present our research dedicated for pwn2own event this year. We will describe kernel part of exploit in detail*, including bug description, resulting memory corruption conditions & caveats up to final pwn via one of our TTF bugs.
Throughout the talk we will describe how to break various exploit mitigations in windows kernel and why it is possible. We will introduce novel kernel exploitation techniques breaking all what stands { KASLR, SMEP, even imaginary SMAP or CFG } and bring you SYSTEM exec (from kernel driver to system calc).
* unfortunately bug was not fixed at the time of talk, so we do not exposed details about TTF vulnerability, and we skipped directly to some challenges during exploitation, and demonstrate how OS design can overpower introduced exploit mitigations.
Injection on Steroids: Codeless code injection and 0-day techniquesenSilo
Most nefarious activities carried out by malware—such as running code in Internet Explorer in an attempt to steal passwords, hijack sessions, or conduct Man-in-the-Browser fraud, require code injection.
This session exposes additional new user- and kernel-mode injection techniques. One of these techniques we’ve coined as “code-less code injection” since, as opposed to other known injection techniques, does not require adding code to the injected process.
Security research over Windows #defcon chinaPeter Hlavaty
Past several years Microsoft Windows undergo lot of fundamental security changes. Where one can argue still imperfect and bound to tons of legacy issues, on the other hand those changes made important shifts in attacker perspective. From tightened sandboxing, restricting attack surface, introducing mitigations, applying virtualization up to stronger focus even on win32k. In our talk we will go trough those changes, how it affects us and how we tackle them from choosing targets, finding bugs up to exploitation primitives we are using. While also empathize that windows research is not only about sandbox, and there are many more interesting target to look for.
Kernel vulnerabilities was commonly used to obtain admin privileges, and main rule was to stay in kernel as small time as possible! But nowdays even when you get admin / root then current operating systems are sometimes too restrictive. And that made kernel exploitation nice vector for installing to kernel mode!
In this talk we will examine steps from CPL3 to CPL0, including some nice tricks, and we end up with developing kernel mode drivers.
As computer systems become more sophisticated, process injection techniques also evolve. These techniques are notorious for their use by "malicious software" to hide code execution and avoid detection. In this presentation we dive deep into the Windows runtime and we demonstrate these techniques. Besides, we also learn how to code construction and design patterns that relate to perform hidden code can recognize.
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.
Pressetation about how to find vulnerabilities and do reversing to the iOS Operating System. The author is Steffan Esser and the talk was delivered in SyScan 2011 in Singapur
Captain Hook: Pirating AVs to Bypass Exploit MitigationsenSilo
In this talk we reveal six(!) different security issues that we uncovered in various hooking engines. The vulnerabilities we found enable a threat actor to bypass the security measures of the underlying operating system. As we uncovered the vulnerabilities one-by-one we found them to impact commercial engines, such as Microsoft’s Detours, open source engines such as EasyHook and proprietary engines such as those belonging to TrendMicro, Symantec, Kaspersky and about twenty others.
Steelcon 2014 - Process Injection with Pythoninfodox
This is the slides to accompany the talk given by Darren Martyn at the Steelcon security conference in July 2014 about process injection using python.
Covers using Python to manipulate processes by injecting code on x86, x86_64, and ARMv7l platforms, and writing a stager that automatically detects what platform it is running on and intelligently decides which shellcode to inject, and via which method.
The Proof of Concept code is available at https://github.com/infodox/steelcon-python-injection
50 Shades of Fuzzing by Peter Hlavaty & Marco GrassiShakacon
Graphic drivers and their related code are an essential component in every modern operating system. This particular component involves especially complex logic and a huge amount of code, simply because it must handle equally complex tasks.
As we know from history and experience huge and complex code is often also a security risk. Last but not least, in almost all the popular modern operating system, graphics code and logic is running in a highly privileged context such as the kernel, or even in a higher context, such as VMWare graphics component, which essentially implements your graphic card outside the guest into a host process.
Any mistake made into this highly privileged code can lead to a fatal outcome, especially considering that it is often reachable from interesting sandboxes, such as the browser ones. We will go through the internals for various graphic systems, to show similarities and differences, such as windows heart of graphics aka win32k, then OSX/iOS IOKit, and finally, WMWare emulated GPU graphic subsystem. We can then switch gear and showcase some vulnerabilities in these scenarios, discuss effective fuzzing methodologies both specific to a particular target and generic principles of fuzzing graphic subsystems as well.
This talk will cover how powerfull are buffer overflows, how weak are mitigations against them, why are buffer overflows still possible in those days, how generic are they, and example how useful is turn race conditions to buffer overflow. Race conditions are nice example for that, because they are one of the hardest to find and on of the easiest to make. example is on Linux kernel (droids included), but talk will be keeped for buffer overflows in general (mainly for windows & Linux kernel)
Surviving the Java Deserialization Apocalypse // OWASP AppSecEU 2016Christian Schneider
The hidden danger of Java deserialization vulnerabilities – which often lead to remote code execution – has gained extended visibility in the past year. The issue has been known for years; however, it seems that the majority of developers were unaware of it until recent media coverage around commonly used libraries and major products. This talk aims to shed some light about how this vulnerability can be abused, how to detect it from a static and dynamic point of view, and -- most importantly -- how to effectively protect against it. The scope of this talk is not limited to the Java serialization protocol but also other popular Java libraries used for object serialization.
The ever-increasing number of new vulnerable endpoints and attacker-usable gadgets has resulted in a lot of different recommendations on how to protect your applications, including look-ahead deserialization and runtime agents to monitor and protect the deserialization process. Coming at the problem from a developer’s perspective and triaging the recommendations for you, this talk will review existing protection techniques and demonstrate their effectiveness on real applications. It will also review existing techniques and present new gadgets that demonstrates how attackers can actually abuse your application code and classpath to craft a chain of gadgets that will allow them to compromise your servers.
This talk will also present the typical architectural decisions and code patterns that lead to an increased risk of exposing deserialization vulnerabilities. Mapping the typical anti-patterns that must be avoided, through the use of real code examples we present an overview of hardening techniques and their effectiveness. The talk will also show attendees what to search the code for in order to find potential code gadgets the attackers can leverage to compromise their applications. We’ll conclude with action items and recommendations developers should consider to mitigate this threat.
--
This talk was presented by Alvaro Muñoz & Christian Schneider at the OWASP AppSecEU 2016 conference in Rome.
Serial Killer - Silently Pwning your Java Endpoints // OWASP BeNeLux Day 2016Christian Schneider
In this session we begin with modelling the attack surface of Java deserialization, which often leads to remote code execution (RCE), by showcasing vulnerabilities we found in modern and widely used applications and frameworks. We extend existing research about risks of deserialization broadening the attack surface. After a live demo of getting a Meterpreter shell in a modern Java endpoint setup we delve into the exploitation styles for this vulnerability to lay the foundation of the first of three key takeaways for the attendees:
The first key takeaway is identification of test types that should be executed during a dynamic assessment of an application in order to find this kind of vulnerability. This includes analyzing the deserialization interface and using blackbox tests to create payloads with gadgets matching the application’s classpath to verify the RCE. Discussion extends to cover indirect deserialization interfaces that use non-binary data formats, such as XML-based interfaces, which can also act as a driver for deserialization within the application.
The next key takeaway covers the realm of static code analysis (SAST). We present code patterns security reviewers should look for when doing whitebox assessments of applications or frameworks. This is especially interesting for code offering dynamic functionality including AOP, generic mappings, reflection, interceptors, etc. - all of which have a high probability of including code that can facilitate as deserialization gadgets and thus help the attackers in exploiting deserialization vulnerabilities. In this section we present the techniques used to find the vulnerabilities within the popular frameworks showcased during the live demo at the session’s start.
Finally we conclude with tips on implementing different techniques of hardening measures for applications offering deserialisation interfaces (either direct binary deserialization interfaces or indirect XML-based ones) to give the attendees the third key takeaway: protecting applications properly. This includes ways to verify data integrity prior to deserialization and ways to properly inspect the data before it’s handled by the Java deserialization process.
--
This talk was presented by Christian Schneider & Alvaro Muñoz at the OWASP BeNeLux Day 2016.
As @nicowaisman mentioned in his talk Aleatory Persistent Threat, old school heap specific exploiting is dying. And with each windows SP or new version, is harder to attack heap itself. Heap management adapt quickly and include new mittigation techniques. But sometimes is better to rethink the idea of mittigation and do this technique properly even half version of it will cover all known heap exploit techniques…
Te invito a conocer el nuevo brochure del Proyecto Costamare, un proyecto único con cerca de 3 hectáreas de áreas sociales, rodeadas por un entorno arquitectónico mediterráneo y acabados con diseños italianos de lujo, muy cerca de todo.
DIDAR: Database Intrusion Detection with Automated RecoveryAsankhaya Sharma
In this project we present a new architecture for database intrusion detection. We
implement this framework called DIDAR (Database Intrusion Detection with Automated
Recovery) and discuss the performance issues. Recently there has been considerable
interest in the design of intrusion detection system for databases. Most of the current
systems take a laid back approach and concentrate more on containment and recovery
once the database has been infected by malicious transaction. We propose a more
proactive solution; DIDAR aims to detect the intrusions as soon as possible with support
for damage containment and auto recovery as well. DIDAR provides intrusion tolerance
by working in two phases – learning and detection. During the learning phase we build a
model of the legitimate queries for each user based on the currently executing
transactions and later use that model to detect the malicious transactions. DIDAR
guarantees quality of information assurance at four different levels for each user. We
have positive results based on our prototype and preliminary testing on synthetic
database. With almost no load to the database DIDAR achieves high detection rates,
quick damage containment and full recovery.
Thee seriousness of the health risks and the expenses associated with treatment can be devastating to victims and their family members. A lawyer for mesothelioma may be able to provide legal advocacy to help. For more details visit: http://mattsharplaw.com/
The Southeastern Interfraternity Conference allowed me to volunteer my services for their 50th anniversary. Featured is the official logo for the Emerging Leader's Institute. This is an original design.
Renderings of the 6-floor retail development at 20 Times Square, below the new Ian Schrager Edition Hotel. Located at 701 7th Ave and 47th St.
20timessquare.com
Traits allow decomposing programs into smaller parts and mixins are a form of composition that resemble multiple inheritance. Unfortunately, in the presence of traits, programming languages like Scala give up on subtyping relation between objects. In this paper, we present a method to check subtyping between objects based on entailment in separation logic. We implement our method as a domain specific language in Scala and apply it on the Scala standard library. We have verified that 67% of mixins used in the Scala standard library do indeed conform to subtyping between the traits that are used to build them.
Pipiot - the double-architecture shellcode constructorMoshe Zioni
Presentation Abstract:
When compiling shellcode - it is always constrained to what architecture you are intended it to run on. So with that thought in mind - I started my latest challenge/research/journey into assembly polyglotism - focusing on the two top main architectures around - x86 and ARM.
Through research, sleepless nights and a lot of coffee (thank you, coffee) I found out that it is, indeed, possible - and, while exploring different routes and directions, devised a constructive, repeatable method.
The Pipiot method is a constructuive way to break the limitation enforced by previously known shellcode construction and make a payload that can run on more than only one architecture of choice.
In this session you will learn on how this system works and how to apply its logic to your exploit payload construction, discuss possible impacts, strong and weak points of the method and of course - all provided with a follow-through live demo.
I think this presentation about Adapteva's Parallella is one of the most comprehensive till now. Feel free to use it. I gave this talk on 10th Dec 2014 at Cloud Research Lab, Ericsson AB, Lund, Sweden.
Ceph: Open Source Storage Software Optimizations on Intel® Architecture for C...Odinot Stanislas
Après la petite intro sur le stockage distribué et la description de Ceph, Jian Zhang réalise dans cette présentation quelques benchmarks intéressants : tests séquentiels, tests random et surtout comparaison des résultats avant et après optimisations. Les paramètres de configuration touchés et optimisations (Large page numbers, Omap data sur un disque séparé, ...) apportent au minimum 2x de perf en plus.
Ice Age melting down: Intel features considered usefull!Peter Hlavaty
Decades history of kernel exploitation, however still most used techniques are such as ROP. Software based approaches comes finally challenge this technique, one more successful than the others. Those approaches usually trying to solve far more than ROP only problem, and need to handle not only security but almost more importantly performance issues. Another common attacker vector for redirecting control flow is stack what comes from design of today’s architectures, and once again some software approaches lately tackling this as well. Although this software based methods are piece of nice work and effective to big extent, new game changing approach seems coming to the light. Methodology closing this attack vector coming right from hardware - intel. We will compare this way to its software alternatives, how one interleaving another and how they can benefit from each other to challenge attacker by breaking his most fundamental technologies. However same time we go further, to challenge those approaches and show that even with those technologies in place attackers is not yet in the corner.
Have you heard that all in-memory databases are equally fast but unreliable, inconsistent and expensive? This session highlights in-memory technology that busts all those myths.
Redis, the fastest database on the planet, is not a simply in-memory key-value data-store; but rather a rich in-memory data-structure engine that serves the world’s most popular apps. Redis Labs’ unique clustering technology enables Redis to be highly reliable, keeping every data byte intact despite hundreds of cloud instance failures and dozens of complete data-center outages. It delivers full CP system characteristics at high performance. And with the latest Redis on Flash technology, Redis Labs achieves close to in-memory performance at 70% lower operational costs. Learn about the best uses of in-memory computing to accelerate everyday applications such as high volume transactions, real time analytics, IoT data ingestion and more.
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
From L3 to seL4: What have we learnt in 20 years of L4 microkernelsmicrokerneldude
History of L4 microkernels. Look at Jochen Liedtke's original design and implementation insights and how they stood the test of time. What do latest-generation microkernels look like, especially seL4
Engage 2020 - Kubernetes for HCL Connections Component Pack - Build or Buy?panagenda
HCL Connections V7 will be based on Kubernetes only! A parallel WebSphere environment won't be necessary any longer. Martin and Christoph collected the basics and differences in building a Kubernetes environment of your choice. They show you a comparison of an on-premises deployment versus a hosted cloud environment (Amazon EKS). After this session you have the basics to size and build a Kubernetes cluster for Component Pack, so you can start learning the new technology to take off with Connections V7 and become a Kubernaut.
Kubernetes for HCL Connections Component Pack - Build or Buy?Martin Schmidt
HCL Connections V7 will be based on Kubernetes only! A parallel WebSphere environment won't be necessary any longer. Martin and Christoph collected the basics and differences in building a Kubernetes environment of your choice. They show you a comparison of an on-premises deployment versus a hosted cloud environment (Amazon EKS). After this session you have the basics to size and build a Kubernetes cluster for Component Pack, so you can start learning the new technology to take off with Connections V7 and become a Kubernaut.
Discusses my 25-year journey for finding the perfect operating-system interface, covering our work on the Mungi single-address-space operating system (SASOS), early work on L4 microkernels, and now the seL4 microkernel, its evolution and verification.
Talk originally given at a seminar series hosted by VMware Research on occasion of the company's 20st anniversary.
Bridging the Digital Gap Brad Spiegel Macon, GA Initiative.pptxBrad Spiegel Macon GA
Brad Spiegel Macon GA’s journey exemplifies the profound impact that one individual can have on their community. Through his unwavering dedication to digital inclusion, he’s not only bridging the gap in Macon but also setting an example for others to follow.
Multi-cluster Kubernetes Networking- Patterns, Projects and GuidelinesSanjeev Rampal
Talk presented at Kubernetes Community Day, New York, May 2024.
Technical summary of Multi-Cluster Kubernetes Networking architectures with focus on 4 key topics.
1) Key patterns for Multi-cluster architectures
2) Architectural comparison of several OSS/ CNCF projects to address these patterns
3) Evolution trends for the APIs of these projects
4) Some design recommendations & guidelines for adopting/ deploying these solutions.
# Internet Security: Safeguarding Your Digital World
In the contemporary digital age, the internet is a cornerstone of our daily lives. It connects us to vast amounts of information, provides platforms for communication, enables commerce, and offers endless entertainment. However, with these conveniences come significant security challenges. Internet security is essential to protect our digital identities, sensitive data, and overall online experience. This comprehensive guide explores the multifaceted world of internet security, providing insights into its importance, common threats, and effective strategies to safeguard your digital world.
## Understanding Internet Security
Internet security encompasses the measures and protocols used to protect information, devices, and networks from unauthorized access, attacks, and damage. It involves a wide range of practices designed to safeguard data confidentiality, integrity, and availability. Effective internet security is crucial for individuals, businesses, and governments alike, as cyber threats continue to evolve in complexity and scale.
### Key Components of Internet Security
1. **Confidentiality**: Ensuring that information is accessible only to those authorized to access it.
2. **Integrity**: Protecting information from being altered or tampered with by unauthorized parties.
3. **Availability**: Ensuring that authorized users have reliable access to information and resources when needed.
## Common Internet Security Threats
Cyber threats are numerous and constantly evolving. Understanding these threats is the first step in protecting against them. Some of the most common internet security threats include:
### Malware
Malware, or malicious software, is designed to harm, exploit, or otherwise compromise a device, network, or service. Common types of malware include:
- **Viruses**: Programs that attach themselves to legitimate software and replicate, spreading to other programs and files.
- **Worms**: Standalone malware that replicates itself to spread to other computers.
- **Trojan Horses**: Malicious software disguised as legitimate software.
- **Ransomware**: Malware that encrypts a user's files and demands a ransom for the decryption key.
- **Spyware**: Software that secretly monitors and collects user information.
### Phishing
Phishing is a social engineering attack that aims to steal sensitive information such as usernames, passwords, and credit card details. Attackers often masquerade as trusted entities in email or other communication channels, tricking victims into providing their information.
### Man-in-the-Middle (MitM) Attacks
MitM attacks occur when an attacker intercepts and potentially alters communication between two parties without their knowledge. This can lead to the unauthorized acquisition of sensitive information.
### Denial-of-Service (DoS) and Distributed Denial-of-Service (DDoS) Attacks
1.Wireless Communication System_Wireless communication is a broad term that i...JeyaPerumal1
Wireless communication involves the transmission of information over a distance without the help of wires, cables or any other forms of electrical conductors.
Wireless communication is a broad term that incorporates all procedures and forms of connecting and communicating between two or more devices using a wireless signal through wireless communication technologies and devices.
Features of Wireless Communication
The evolution of wireless technology has brought many advancements with its effective features.
The transmitted distance can be anywhere between a few meters (for example, a television's remote control) and thousands of kilometers (for example, radio communication).
Wireless communication can be used for cellular telephony, wireless access to the internet, wireless home networking, and so on.
APNIC Foundation, presented by Ellisha Heppner at the PNG DNS Forum 2024APNIC
Ellisha Heppner, Grant Management Lead, presented an update on APNIC Foundation to the PNG DNS Forum held from 6 to 10 May, 2024 in Port Moresby, Papua New Guinea.
This 7-second Brain Wave Ritual Attracts Money To You.!nirahealhty
Discover the power of a simple 7-second brain wave ritual that can attract wealth and abundance into your life. By tapping into specific brain frequencies, this technique helps you manifest financial success effortlessly. Ready to transform your financial future? Try this powerful ritual and start attracting money today!
1. Shooting the OS X El Capitan Kernel
Like a Sniper
Liang Chen @chenliang0817
Qidan He @flanker_hqd
2. About us
• Liang Chen
• Senior Security Researcher
• Main focus: browser vulnerability research, OS X kernel, Android Root
• Qidan He
• Senior Security Researcher
• Main focus: Sandbox escape, mobile security, Kernel research
• Tencent Security Team Sniper (KeenLab and PC Manager) won Master
of Pwn in this year’s Pwn2Own
3. Agenda
• OS X kernel exploitation mitigation recap
• New approach to exploit kernel under sandboxed process
• Demo
4. OS X kernel mitigation
• kASLR
• kslide is assigned upon booting. (Kexts and kernel share the same slide)
• DEP
• Disallow kernel RWX
• SMEP
• Disallow kernel code execution from userland address space
5. Mitigation introduced by El Capitan
• SMAP
• Disallow memory access from userland address space
• Enabled only on supported CPU architecture
• From unsupported architecture
• Supported architecture
6. Mitigation introduced by El Capitan
• OOL leak mitigation 1: Structure change in vm_map_copy
After El CapitanBefore El Capitan
Kdata pointer is good candidate for AAR with overflow
vulnerability
Kdata pointer is removed
7. Mitigation introduced by El Capitan
• OOL leak mitigation 1: Structure change in vm_map_copy
• Still able to achieve limited OOB read, by increasing size field
• “OS X kernel is as strong as its weakest part”:
http://powerofcommunity.net/poc2015/liang.pdf
• “Free to other zone” approach by @qwertyoruiop:
• “Attacking the XNU Kernel in El Capitan”: https://www.blackhat.com/docs/eu-
15/materials/eu-15-Todesco-Attacking-The-XNU-Kernal-In-El-Capitain.pdf
8. Mitigation introduced by El Capitan
• OOL leak mitigation 2
• Introducedin 10.11.1
• Changing size field can lead to panic when reading/receiving OOL data
9. Mitigation introduced by El Capitan
• OOL leak mitigation 2:What happened
mach_msg_ool_descriptor_t vm_map_copy
Two redundant size fields
10. Mitigation introduced by El Capitan
• OOL leak mitigation 2
• Check mach_msg_ool_descriptor_t.size == mach_msg_ool_descriptor_t.address.size
Panic if size mismatch
What if copy->size is
modified in between?
TOCTTOU? Ah!
11. Mitigation introduced by El Capitan
• OOL leak mitigation
• Make general info leak approach harder
• Still vulnerable
• TOCTTOU issue exists (Although very small time window)
• Other approaches
• Effective mitigation
• Harder kernel exploitation
• Even for perfect overflow vulnerability (length + content both controllable)
12. OS X kernel exploitation requirement
• Leak kslide
• vm_map_copy followed by vtable object - Mitigated
• Leak address pointer of controllable data
• Bypass SMAP/SMEP
• Needed by both ROP approach and AAR/AAW primitive approach
• mach_port_kobject – Mitigated
• Even worse thing is…
• We need perfect overflow bug to achieve those
• Many bugs/exploitation approach are not reachable from remote attack
surface (Safari browser)
13. How about non-perfect write? Even harder…
Remind me the hard time of IE exploitation in 2012...
14. Memory Spraying
• Heap spraying concept on browsers
• Helpful to exploitation development (Extremely useful before we got info leak)
• Widely used on 32bit systems
• Effective when memory is larger than address space
• On 64bit systems, less effective
Run the code three times:
Result in:
256 * 4G memory to reliably fill specific data at target address
15. Memory Spraying in Kernel
• OOL vm_map_copy is still good candidate for memory spraying
• OOL data keeping in kernel before receiving
• But…
• OS X Kernel is 64bit
• Address space larger than physical memory
• Seems hard?
16. Memory Spraying in Kernel
• Question?
• Is OS X Kernel address space really large (than physical address) ?
• kalloc random?
17. Memory Spraying in Kernel
• Kernel/Kext text base
• Fixed base + kslide
• Kslide range : (0x00 – 0xff)<<21, max 0x1fe0 0000
• Address coverage less than 512MB + Kernel + Kext size
• Much smaller than physical memory size
• Kernel/Kext data base
• Fixed base + kslide
• Much smaller than physical memory size also
18. Memory Spraying in Kernel
• How about kalloc zone address
• zone_map->hdr.links.start
• Heavily dependent on kslide
• Not too far away from the end of kernel
• Allocationstarts from low to high
zone_map.hdr.start kslide zone_map.hdr.start - kslide
0xffffff803b1d4000 0x1c400000 0xffffff801edd4000
0xffffff802071e000 0x1800000 0xffffff801ef1e000
0xffffff80247cc000 0x6a00000 0xffffff801ddcc000
0xffffff803610c000 0x18200000 0xffffff801df0c000
19. Memory Spraying in Kernel
• Conclusion
• Spray with OOL approach
• With more than 512 MB * 2
• Reliable (Controllabledata at fixed address)
21. Memory Spraying in Kernel
• Why spraying?
• A good workaround to leak some kalloc-ed address
• Locate kernel ROP chain to bypass SMAP/SMEP, thanks to OOL’s spraying
feature
• Other good features to help our “Sniper”
• Sniper means remotely (from browser), faraway (address), but reliable
25. Found a write-something vulnerability?
• Write anything anywhere – piece of cake
• Write *more* *restricted* something anywhere?
• What if you can only write eight floats continuously in range [-0xffff,
0xffff]?
• Translate to range
• 0x3f800000 3f800000 - 0x477fff00 477fff00
• 0xbf800000 bf800000 - 0xc77fff00 c77fff00
28. Challenge #1
• Overwriting vm_map_copy length?
• Apple fixed that in 10.11.1
• Still have ways to bypass...
• Not applicable to our vulnerability
• Why?
• Adjacent write
• Write value qword not good
• 0x3f....3f....
• 0xbf....bf....
• Overwriting some address?
31. • Why not overwrite vptr at head of userclients?
• High bytes are 0xffffff7f, address content not controllable
• Except RootDomainUserClient
• But size too small … problems?
• N*PAGE_SIZE allocations are more reliable and predictable
• Speed issues
37. 0
50
100
150
200
250
300
350
400
450
500
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
Total Spray Time
0
5
10
15
20
25
30
35
40
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
Average Spray Time
It’s in 2016 and we still have a O(N^2) time
complexity function in the core of a modern
operating system…
(X axis multiply by 0x500*5, y axis in second)
38. Hey man check your accelerator
• Nearly all IOAcceleratorFamily2 userclients have a `service` pointer
associated
• Point to IntelAccelerator
• Virtual function calls
• Heap location starts with 0xffffff80 yeah
• Overwrite it and point it to controllable memory!
44. Leaking strategy
• By spraying we can ensure 0xf… 62388000(A) (lies an
IGAccelVideoContext
• And 0xf... Bf800000(B) lies an vm_map_copy with size 0x2000
• Overwrite the service pointer to B, point to controlled vm_map_copy
filled with 0x4141414141414141 (at 0x1288 set to A - 0xD0)
• Test for 0x41414141 by calling get_hw_steppings on sprayed
userclients
• If match, we get the index of userclient being corrupted
• a2[4] returns a byte at A!
52. Replace with …N
+1000
Fill ool_msg with service offset point to
0xf… …N
Trigger IOConnect
Call
Leaked byte zero?
let N=N+1, free
and refill ool_msgs
KEXT vptr leaked
8 bytes all leaked?
kernel offset
leaked
redo with vptr value
53. Leaking strategy
• We can use an additional read to determine if the address is at A or
A+0x1000
• If we try A but its actually at A+0x1000, we will read byte at +0x1000 of
IGAccelVideoContext, which is 0, then we can try again with A+0x1000 to read
the correct value
• Free and fill the vm_map_copy living at B to increment the location to
read by 1 byte
• Free and fill vm_map_copy , modified with leaked vptr to leak kernel
section offset, thus kslide
• Better way exists - exercise for readers J
54. Final workflow
• Spray 0x50000 ool_msgs with data size 0x2000 (2GB), taint with
0x41414141, write A at 0x1288 and 0x288 offset
• Free middle parts of ool_msgs, fill in IGAccelVideoContext
• Trigger oob write at A - 0x4 + 0x528 and A -4 + 0x528 +0x1000
• Iterate all opened IGAccelVideoContext userclients, call get_hw_steppings
and look for 4141, adjust 0x1288 and 0x288 if needed
• Change to A+0x1000 if 0 got
• Advance read location 1byte by 1, read out KEXT vtable address and then
kern address offset
• Refill ool_msgs bundled with ROP chain, call context_finish
• Pwn