 |
white paper |
 |
presentation |
 |
source |
Bill Woodcock will address past and current efforts to curtail nation-state cyber-attacks on the private-sector core infrastructure of the Internet. From the live fire cyber exercises of the dot-com era and the US-China-Russia cyber-conflicts and United Nations "Group of Government Experts" of the subsequent decade to the current effort of the Global Commission on the Stability of Cyberspace, Bill will discuss the misaligned incentives that encourage militaries to focus on cyber-offense while ignoring defense, the direct effects and blowback that endanger the central infrastructure of the Internet, and the economic costs these attacks impose on Internet users.
The Initial Coin Offering (ICO) boom has been powered by smart contracts, making them a hotter and more lucrative target than ever before. One might expect that being well-funded by security-sensitive investors would be enough to save this technology from the security sins of its forebears. Unfortunately, smart contract security is poorly understood, even by some of the field's most prolific and successful developers. However, the wider Ethereum community is working to change that. An amalgam of academics, security enthusiasts, and industry professionals have created the first generation of audit and development practices focused on defense of smart contracts, along with a nascent tool suite to augment them.
This talk presents a digestible but robust set of tools and practices used by the authors to find real vulnerabilities in real contracts during the course of their work as security consultants. Audience members who develop smart contracts will leave with a strong understanding of development and test best practices to make sure they are not the next to be "popped", while those interested in auditing them will learn a battle-tested practicum for finding vulns in the wild.
We propose a new exploit technique that brings a whole-new attack surface to bypass SSRF (Server Side Request Forgery) protections. This is a very general attack approach, in which we used in combination with our own fuzzing tool to discover many 0days in built-in libraries of very widely-used programming languages, including Python, PHP, Perl, Ruby, Java, JavaScript, Wget and cURL. The root cause of the problem lies in the inconsistency of URL parsers and URL requesters.
Being a very fundamental problem that exists in built-in libraries, sophisticated web applications such as WordPress, vBulletin, MyBB and GitHub can also suffer, and 0days have been discovered in them via this technique. This general technique can also adapt to various code contexts and lead to protocol smuggling and SSRF bypassing. Several scenarios will be demonstrated to illustrate how URL parsers can be exploited to bypass SSRF protection in real bug bounty programs and achieve RCE (Remote Code Execution) in our GitHub Enterprise case.
Understanding the basics of this technique, the audience won't be surprised to know that more than 20 vulnerabilities have been found in famous programming languages and web applications aforementioned via this technique.
In today's mobile world, wireless technology is used in many places. We use it to access online while on the go, connect mobile accessories to a PC, listen to music on the phone, and browse e-mail. Because wireless technology is so universally used, we often think it is safe. However, many of us use wireless technology to enter passwords, send personal data, and share confidential information. In reality, if every point in a wireless communication system has potential vulnerabilities and proper security measures are not in place, personal information can be compromised. We are targeting wireless keyboards based on encryption that are widely used in the real world.
Our attack was conducted in a black box manner for the target device, with the exception of the public information. As a result of the attack, we can obtain a 128-bit secret key that is used to encrypt the plaintext when a user types the wireless keyboard. We provide a method to analyze specifically the internal behavior of the target device and provide a template generation method for side-channel attacks. It also shows how you can extract the encryption key from other wireless keyboards using the same chip.
Therefore, we can decrypt all the input data even if the user encrypts using the encryption-based wireless keyboard and transmits the encrypted data. The most important part of our contribution is that we have identified problems with wireless keyboard devices that have similar product configurations and provide our know-how to analyze similar vulnerabilities. Our results show that the combination of reverse engineering and side-channel attacks has a significant impact on the security of embedded devices.
Mobile payment is gaining huge popularity because of the convenience and security it provides. However, according to our latest findings, popular mobile payment schemes - to provide smooth user experience to users even with poor network connectivity - expose a lot of vulnerabilities in which adversaries can readily acquire the payment token during a valid mobile payment transaction. With this payment token, the attacker can purchase anything under the limit on behalf of the user without the victim noticing.
We successfully launched attacks against mainstream mobile payment service providers including Alipay and Samsung Pay. The results show that they are all vulnerable. More severely, for Alipay, different payment methods are found vulnerable, including QR code and sound pay.
All of these attacks are due to the weak protection to the payment token, the key element for the payment security. Payment tokens are designed to be ephemeral and hard to sniff. However, experimental results show that the token can be intercepted without the payment server noticing. In addition, the stolen token can be kept alive for a considerable period of time, during which the attackers can spend it.
We believe the current payment framework should be updated to defend against these attacks. As a preliminary idea, we suggest that every token should be bound to a specific transaction, even without the help of networks.
This presentation concerns a dissection of QNX: a proprietary, real-time operating system aimed at the embedded market. QNX is used in many sensitive and critical devices in different industry verticals and dominates the automotive sphere. While some prior security research has discussed QNX, mainly as a byproduct of BlackBerry mobile research, there is no prior work on QNX exploit mitigations or its secure random number generators.
This work seeks to address that gap by presenting the first reverse-engineering and analysis of the exploit mitigations, secure random number generators and memory management internals of QNX. We dissect the NX / DEP, ASLR, Stack Cookies and RELRO mitigations as well as the /dev/random and kernel PRNGs of QNX versions up to and including QNX 6.6 and the brand new 64-bit QNX 7.0 released in March 2017.
We subsequently uncover a variety of design issues and vulnerabilities in these mitigations and PRNGs which have significant implications for the exploitability of memory corruption vulnerabilities on QNX as well as the strength of its cryptographic ecosystem. Finally, we provide information on available patches and hardening measures available to defenders seeking to harden their QNX-based systems against the discussed issues.
Microsoft Control Flow Guard (CFG) is the Control Flow Integrity mechanism currently in place on all Windows operating systems, from Windows 8.1 to the most recent update of Windows 10, protecting more than 500 million machines.
We built an attack against Windows CFG that completely evades integrity checks and transfers control to any location, thus obtaining arbitrary code execution. We leverage a significant design tradeoff of CFG between precision, performance, and backwards compatibility; in particular, the latter one motivates 16-byte address granularity in some circumstances. This vulnerability, inherent to the CFG design, allows us to call gadgets that should not be allowed, and that we chain together to escape CFG.
These gadgets are more common that one would expect: we ran a thorough evaluation of Windows system libraries, and found many high value targets – exploitable gadgets in code loaded by almost all the applications on 32-bit systems and by high value targets (such as Edge and Internet Explorer) on 64-bit. Every application that loads these gadgets is exposed to our attack, which proves to be universal enough to be very practical.
In this talk, we will present how we noticed this design vulnerability, how we built our attack on top of it, and its prospected impact. On top of that, we show its real-world feasibility by using it as part of a remote code execution exploit against the Microsoft Edge web browser running on 64-bit Windows 10. All thanks to less than 16 bytes.
When an attacker finds an AWS access key, it's like an unscratched instant lottery ticket. If they're lucky, the prize is full control of your cloud infrastructure. If they're unlucky, it's just an information disclosure vector that leads to more chances for them to win. PROJECT SPACECRAB turns every ticket into a losing ticket, that also alerts your security team that the ticket has been scratched.
SPACECRAB lets you generate, annotate and alert on AWS keys configured as honey tokens at scale. Using your CI/CD or orchestration infrastructure you can put them anywhere, even across your supply chain, and when bad actors find them, they'll use them. Alarms will go off and you'll know not only that you are breached, but where.
We'll also present some data on how and when compromised AWS keys are abused in the wild.
In modern businesses, code obfuscation has become a vital tool to protect, for example, intellectual property against competitors. In general, it attempts to impede program understanding by making the to-be-protected program more complex.
In our talk, we will give an overview of contemporary (binary) code obfuscation techniques, including Mixed Boolean-Arithmetic and Virtual Machines. We further note a common theme in state-of-the-art deobfuscation techniques: They mostly use a mixed approach of symbolic execution and taint analysis; two techniques that require precise analysis of the underlying code. Also, these techniques require a non-trivial amount of domain knowledge. This limits the applicability of these techniques and hints at the necessity of finding alternative approaches to tackle the problem of code obfuscation.
Consequently, we introduce program synthesis as a promising technique that is orthogonal to traditional deobfuscation techniques. As program synthesis can synthesize code of arbitrary code complexity, it is only limited by the complexity of the underlying code's semantic and thus overcomes some of the limitations traditional approaches suffer from.
We show how program synthesis-based techniques can be applied to modern, commercial protection systems such as Themida and VMProtect. Further, we discuss the role of program synthesis in the landscape of modern deobfuscation techniques.
Attackers think in graphs – this has been a known fact for quite a while. Defenders have been thinking in lists for a long time - mapping the users to the resources they are allowed to access and building security systems on top of that information. However, with the constantly changing security landscape, attackers are getting more sophisticated and defenders must adapt accordingly. Therefore, defenders have also started thinking in terms of graphs, mostly to understand and detect potential attacks in large environments.
However, we believe that defenders are not close to exhausting all the possibilities that graphs can offer, and this is the main topic of our talk. We will show numerous ways in which graphs can be useful to not only detect and analyze attacks, but also find various security risks in the system, along with the corresponding mitigations. Some of the topics we will cover include: how the most sensitive machines in an organization can be detected, how to find sensitive accounts which might put the entire environment at risk and how to disconnect nodes in the graph in the most efficient way (without computing the entire graph, which might be consuming in terms of running time & computational resources).
Recently, operators behind exploit kit-as-a-service offerings have put more effort into hiding their operational infrastructure while providing better service to their customers. Namely, almost all popular exploit kits nowadays are operated using sophisticated networks of several servers such as proxies or gates, VDS (Virtual Dedicated Server), rotators, uploaders, panel servers, APIs and more. This complex setup makes it very hard for researchers to analyze the inner workings of these networks, thus limiting the information security community's ability to respond to such threats. However, this customer facing approach also exposes the operators to direct attacks from researches.
Over the past year, we have replicated several exploit kit infrastructures from leaked sources. This allowed us to gain a deeper understanding of their inner workings, choke points, and weaknesses. We discovered several attacks with the potential to take down an exploit kit that may be performed with nothing but regular customer privileges. We also found that code and design-pattern re-use among different exploit kits is frequent, thus allowing us to use the same attacks against several networks and even discover new malicious servers. It is likely that the same approaches will work for the detection and takedown of future exploit kits as well. In this presentation, we will share our findings, analytical approaches and recommendations for future engagement with similar offerings. We will also share insights into the customers of these services.
Nation-states have ruled the Earth since 1648, but they will not survive the Internet. Cyber security is an international problem that requires an international solution. Nations must collaborate and find allies in cyberspace. This talk gives an update on cyber diplomacy and arms control, and offers practical advice on advancing international partnerships at the state and non-state levels.
As we all know, WannayCry has caused terrible disturbances worldwide to Windows PC, utilizing remote 0day SMB vulnerability. The Apple platform (especially the iOS operating system) is imaged to be immune to such kinds of security threats because of its declared system security feature by design and restrict Apple Store security policy. However, we found - possibly for the first time - a suspected ransomware remote attack towards iOS and OSX platforms distributed in the wild.
In this paper, we would like to tell you the whole story of how we hunt for the remote iOS ransomware attack based on profile installation and defeat it in cradle. We will analysis how the iOS ransomware hijacks your phone screen or even causes system crashes or hang using profile installation - as we call "death profile" - in technical detail. We will also introduce both static and dynamic solution to detect and remediate such threat. Thus, we would propose one new remote attack interface on iOS system research.
AMSI is a new mechanism introduced by Microsoft in order to combat the increasing number of malware written in powershell or other scripting languages. AMSI allows any app (such as powershell.exe) to send scan requests to AMSI. Any antimalware product can register its own provider to receive scan requests. This allows the antimalware to, for example, examine powershell code right before it executes, after all deobfuscation has already taken place.
There is no documentation online on how third party creators of antimalware products can register their own AMSI provider to receive scan requests from apps. We took the liberty of understanding how the new AMSI mechanism in Windows 10 works. After having understood how the mechanism is designed, I took a deeper look at how AMSI initializes itself, loads the registered providers, and dispatches scan requests from apps.
In this talk, we will present the internals of AMSI, and publicly disclose, for the first time, how to implement and register a provider. I will also present a number of ways to bypass AMSI, one of which is brand new, and is possible because of the design of the AMSI scan dispatcher.
eMMC & UFS security is one of the critical but mostly overlooked areas in the mobile security today. Being situated in a typical mobile platform architecture on a very low level, eMMC & UFS subsystems provide abilities to control processes from the earliest stages of establishing the chain of trust and then, through the whole mobile platform operation life-cycle. Security mechanisms, implemented in eMMC & UFS, play a very critical role in mobile platforms security architectures. Compromising these security mechanisms leads to compromising of mobile platforms security itself. All these factors make eMMC & UFS subsystems a perfect target for malicious attackers with a potentially huge impact on mobile platforms security and privacy of their users.
The presentation starts with the introduction of Hourglass Model 2.0, a research framework allowing researchers with limited access to underground marketplace to further collect security intelligence leads that can be used for both threat prevention and and mitigation plan development. To better understand how to utilise this model, the second part of this talk will use an on-going research on 2FA bypassing underground services based in Southeast Asia, as an example. Researchers took an unseen, underground advertisement and initiated serious research on threat actor profiles, tools, tactics, procedures, victims, and the overall underground market landscape. The presentation is designed to share what we have learned so far and provide early warnings to the security community.
The power consumption of PCs, laptops, and servers is important because it is related to cost and battery running time. The PC, laptop, and server environments that support advanced configuration and power interface (ACPI) provide six sleeping states (S0-S5) for reducing power consumption according to the operating status. In the sleeping state, CPU, device, and RAM are shut down as the steps of sleeping states increase.
When the system shuts down the components, the system can dramatically reduce power consumption. However, there is a disadvantage that the system should reinitialize the components. Initializations of the components take time to wake up and cause temporary shutdowns of security devices. UEFI firmware uses S3 bootscript to reduce time consumption and reactivates the security devices as soon as possible. Unfortunately, these increase the attack surface.
In this talk, we present how we neutralize the Intel TXT (Trusted eXecution Environment) using S3 sleeping state. Intel TXT is the hardware-based mechanisms that support dynamic root of trust measurement (DRTM) and validate platform trustworthiness during boot and launch. Intel TXT works with Trusted Platform Module (TPM) and extends the hashes of software to platform configuration registers (PCRs). The DRTM PCR values of the TPM are set first by the Intel TXT, and it is difficult to reset them to specific values. To show that Intel TXT can be neutralized, we targeted tBoot, a reference implementation of Intel TXT technology. The tBoot is an open source project and protects the VMM (Virtual Machine Monitor) and OS. We found some flaws of tBoot and confirmed that we could neutralize Intel TXT by resetting the PCRs to specific values using tBoot flaws and S3 sleep. These attacks have never been published before and we will share our research results.
ICU (International Components for Unicode) is a mature, widely used set of C/C++ and Java libraries providing Unicode and Globalization support for software applications. ICU is widely portable and gives applications the same results on all platforms and between C/C++ and Java software. ICU vulnerability is usually not considered severe, since they are unlikely to be exploitable. In browsers such as Chrome, Safari and Firefox, the parameters of the ICU API is always strictly filtered by the frontend. As a result, ICU vulnerability usually cannot be triggered from JavaScript.
We tried to fuzz ICU, with hundreds of crashes produced in one hour. However, most of the crashes are useless because the parameters that produced the crashes can never bypass the filters in browser. After months of study, we found a more efficient way to fuzz ICU. We treat the input data provided by libFuzzer as serialized recipe objects which contain information regarding whether or not to call some ICU API, and how to pass the parameters to the API. After the data was deserialized into recipe objects, the fuzzer will do the specific actions that the recipe objects dictate. For each parameter, the fuzzer can check if it can bypass the filters of a browser. Finally, we hunted 2 memory corruption ICU bugs worked in Chrome, and 1 Out-of-Bound ICU bug worked both in Chrome, Safari, and Firefox. The OOB bug exists in ICU for over 5 years from version 50rc published on 2012 Oct. 22.
For over 70 companies and organizations, hundreds of software use ICU - including very popular software such as Chrome, Android, macOS, iOS, Windows 10, Edge, Firefox. Even cars such as Audi, BMW and more are using ICU. It is estimated that billions of devices maybe be affected for over 5 years. In this presentation, we will talk about our serialized fuzzing approach to hunt for ICU vulnerabilities that can be reached from JavaScript. And finally, we will show the 3 vulnerabilities we found and how to exploit.
Skilled attackers continually seek out new attack vectors and effective ways of obfuscating old techniques to evade detection. Active defenders can attest to attackers' prolific obfuscation of JavaScript, VBScript and PowerShell payloads given the ample availability of obfuscation frameworks and their effectiveness at evading many of today's defenses.
However, advanced defenders are increasingly detecting this obfuscation with help from the data science community. This approach paired with deeper visibility into memory-resident payloads via interfaces like Microsoft's Antimalware Scan Interface (AMSI) is causing some Red Teamers to shift tradecraft to languages that offer defenders less visibility. But what are attackers using in the wild?
In the past year, numerous APT and FIN (Financial) threat actors have increasingly introduced obfuscation techniques into their usage of native Windows binaries like wscript.exe, regsvr32.exe and cmd[.]exe. Some simple approaches entail randomly adding cmd[.]exe's caret (^) escape character to command arguments. More interesting techniques like those employed by APT32, FIN7 and FIN8 involve quotes, parentheses and standard input.
The most interesting obfuscation technique observed in the wild was FIN7's use of cmd[.]exe's string replacement functionality identified in June 2017. This discovery single-handedly initiated my research into cmd[.]exe's surprisingly effective but vastly unexplored obfuscation capabilities.
In this presentation, I will dive deep into cmd[.]exe's multi-faceted obfuscation opportunities beginning with carets, quotes and stdin argument hiding. Next I will extrapolate more complex techniques including FIN7's string removal/replacement concept and two never-before-seen obfuscation and full encoding techniques – all performed entirely in memory by cmd[.]exe. Finally, I will outline three approaches for obfuscating binary names from static and dynamic analysis while highlighting lesser-known cmd[.]exe replacement binaries.
I will conclude this talk by releasing a new cmd[.]exe obfuscation framework called Invoke-DOSfuscation that obfuscates payloads using these multi-layered techniques. I will also share detection implications and approaches for this genre of obfuscation.
Recently, Android 8.0 has released, born with new kernel harden features and more strict SELinux policies enforcing. Rooting large numbers of newest Android devices with one single vulnerability is quite a challenge.
In this talk, we will first detail a new rooting solution ReVent. It derives from a Use-After-Free vulnerability due to race condition, which affects all the Android devices shipped with >=3.18 Linux kernel, and can be executed by any untrusted application. Since many different slab objects are frequently allocated/freed on the same heap during exploiting process, it's quite challenging to shape heap Fengshui and achieve kernel code execution. We will demonstrate how to use the TOCTOU feature of pipe subsystem to gain arbitrary kernel memory overwriting.
It's no doubt that using the old public exploitation technique like overwriting ptmx_fops to bypass PXN is straightforward. Unsurprisingly, it can hardly defeat "Oreo" due to PAN mitigation. To bypass PXN and PAN mitigation on Android 8.0, we will introduce a new kernel exploitation technique, named Kernel Space Mirroring Attack(KSMA). It derives from ARM MMU features and enables an attacker to r/w kernel text/data virtual address from user mode(EL0) without any syscalls. Combined with the above vulnerability, the newest Android 8.0 devices can be rooted.
Another rooting solution CPRooter will also be detailed in this presentation. The vulnerability, which affects large numbers of Qualcomm Android devices, enables an attacker to r/w the TTBRx registers. Without constructing all level page tables, modifying the value of any TTBRx registers can lead to the kernel crash. We will demonstrate how to solve the problem with ARM MMU features and construct a 100% reliable exploit chain on Android 64-bit devices using KSMA exploitation technique.
In summary, the ideas of exploitation are fresh, and the new exploitation technique KSMA against Android 8.0 we proposed has never been discussed before.
At the close of this year's conference, join Black Hat Founder Jeff Moss and members of the esteemed Black Hat Review Board for an insightful conversation on the most pressing issues facing the InfoSec community. This Locknote will feature a candid discussion on the key takeaways coming out of Black Hat Asia and how these trends will impact future InfoSec strategies.
As Mac systems grow in popularity, so does macOS malware - whilst macOS malware analysis is still lagging behind - particularly when we deal with malicious behaviors in the user space.
To amend this shortcoming, we have come up with macOS analyzer for malware – Mac-A-Mal: a system for behavioral monitoring of components at kernel level which allows analysts to automatically investigate malware on macOS, broadly extending what is available today with Cuckoo sandbox. By leveraging on kernel-level system calls hooking, the framework is able to detect and mitigate malware anti-analysis techniques. In particular, it combines static and dynamic analysis to extract useful information and suspicious behaviors from malware binaries, their monitored behaviors such as network traffic, malware evasion techniques, persistence methods, file operations etc., without being detected by common Mac malware evasion techniques.
We have used the framework to evaluate thousands macOS samples to estimate how widespread Mac malware variants and families are today (thanks to VirusTotal). Mac malware in 2017 demonstrates a drastic improvement by using evasion techniques. Overall, we used our systems to classify the dataset and found that 85% of collected samples are adware, 49% of classified variants belongs to backdoor/trojan.
By hunting Mac samples on VirusTotal, we found an undiscovered-so-far organized adware campaign which leverages several Apple legitimate developer certificates, few other undetected keyloggers, and trojan samples participating in APT32 OceanLotus targeting Chinese and Vietnamese organizations, as well as hundreds of malware samples which have otherwise low detection rates.
Lazarus, Bluenoroff, and Andariel are three notorious APT groups which are believed from the same country infamous for deconstruction, cyber heist, and espionage attacks. From DarkSeoul to Sony Picture Entertainment breach, the groups conducted several operations that have attracted international public attention.
Starting from 2016, we have observed a significant change in the targets and motivation of these groups. While the groups have a long history of conducting cybercrime and cyber espionage attacks, their operations have become more aggressive and more focused on the cybercrime attacks targeting financial institutions. In February 2016, a series of attacks from Lazarus group - which leveraged the SWIFT banking network used to target Bangladesh banks - were revealed. Later in May, the global WannaCry ransomware attack was also linked back to the nation. However, these attacks were just the tip of the iceberg.
In this talk, we will disclose four recent campaigns conducted by the groups. These campaign targeted banks in South Korea and EMEA, an ATM company and several Bitcoin exchanges service provider. We will introduce the malware, vulnerabilities, IOC, and attack vectors discovered in these attacks. In addition, we will explain how we uncovered the new C&C infrastructure acquired through bitcoin payment and the TTP key-finding we summarized from their recent operations. In the hope of making the world a safer place, we disclose this information to help financial institutions react to the substantial threat.
In the 64-bit linux kernel - in order to be compatible with 32-bit process - compat system call is added in linux kernel to ensure that the 32-bit process can normally run in the 64-bit linux system as 64-bit process. In achieving the same function in the kernel, it is usually required to implement the compat interface and non-compat interface respectively. Therefore, two different codes need to be maintained. On the one hand, the separation of this definition easily lead to a greater code maintenance work, while the update for the two codes may be out of sync. On the other hand, since the compat interface is not always triggered in the 64-bit system, the underlying logic problem is not easily found by the developer, even tools such as trinity and syzkaller may ignore the fuzzing test for compat interface.
Since 64-bit linux kernel has come into being, compat's security vulnerabilities have been constantly disclosed. In the past year, there have been a number of compat-related vulnerabilities disclosed in the Android Security Bulletin. However, these founded vulnerabilities are mostly common seen with familiar names: out-of-bounds access of arrays, heap overflow, stack overflow and so on.
This time, by taking Android Qualcomm platform driver as an example, we will show a new attack surface on the compat, and how to discover several types of vulnerabilities through this attack surface. At the same time, such vulnerabilities may also prevail in driver programs of other platforms and even in the kernel itself.
Our attack on these vulnerabilities are mainly utilizing a neglected logic defect when the compat interface is performing compatibility conversion, which will then bypass the length of the array, user memory pointer checks contained in the conversion process. Since the necessary conversion and validation check is lost, user input with malicious value is directly received and processed by the non-compat interface, further triggering the vulnerability.
We have discovered a number of device driver vulnerabilities on Android Qualcomm platform by applying this method and submitted them to Google and Qualcomm.
In recent years, Google has been committed to improving the security of the Android ecosystem. To better protect the kernel, Google has enabled a number of mechanisms including PXN, SELinux and so on. At the same time, some smartphone OEMs also make additional protection for their own products. As a result, vulnerability exploitation is becoming more and more challenging.
In the second quarter of 2017, Samsung, HUAWEI, OPPO and vivo account for 47.2 percent of the global market share. For the world's top four Android smartphone OEMs, there have only been some related researches on the Samsung KNOX. Considering the other three OEMs also occupy large global market share, we conducted an in-depth research on their mitigations and got some interesting discoveries.
In this talk, we will disclose all details of these mitigations and show how to bypass them stably, which have never been made public. In addition, some practical suggestions for the improvement of these protective mechanisms will be discussed during the presentation.
In this talk, we will present "return-to-csu" - a new method to bypass the ASLR in 64-bit Linux systems. The method is generic, since it does not use the compiled code from the target application but code that is always "silently attached" to it. This, in practice, means that our attack can be applied to any application. We will present our analysis, which reveals who is attaching this "extra code" to the executable memory (not to the shared libraries memory region) and why this code can not be easily protected/removed by application developers.
Although the idea of incremental compilation to do less work sounds generally good, it could raise some security issues. Having code which is not re-compiled could result in old or less protected code that can be abused by attackers. As a proof of that, we will present an attack abusing this extra code to bypass the ASLR in 64-bit Linux systems.
We will briefly describe the code that is out of the developers control, showing why it is "unsafe" and how it can be abused finding that there are enough assembler instructions that can be used to created what we named "return-to-csu" - a method to bypass the full Linux ASLR in 64-bit systems in a reliable, fast and generic way.
We will disclose the exploit and a live proof of concept using the return-to-csu method to obtain a shell in less than 1 second. The attack works on PIE and non-PIE applications as well as on hardened (PaX) systems. To make it more realistic, in the demonstration we will also bypass the NX, SSP, RELRO and other protections. To illustrate the method we will exploit, we will use a classic stack buffer overflow showing that a stack buffer overflow is synonymous of having a remote shell even in current 64-bit full protected application in most of the cases.
Finally, we will discuss the root cause and provide some recommendations to prevent the return-to-csu attack.
Trusted Execution Environments (TEEs) are present in many devices today, and are used to perform security critical computation in an isolated environment. ARM's TrustZone is one of the most widely used TEEs in the world today, present in nearly every modern Android device.
TrustZone allows developers to write applications that run in a "Secure World" with hardware isolation of resources. Most implementations use a Trusted Operating System to run multiple Trusted Applications.
However, Trusted Applications are still written in C, and many common classes of vulnerabilities have been found in these applications. While TrustZone provides isolation of resources, it cannot prevent against vulnerable code.
In this talk, we will explore using the Rust language to write a Trusted Application. Rust allows developers to write system-level code, but provides security features including memory safety, type safety, and error handling. These are desirable features for development of Trusted Applications.
We will begin with an overview of TrustZone and Rust language, then show how Rust can be used to develop a Trusted Application. To conclude, we will demo a Trusted Application on real TrustZone hardware.
Wearable platforms today enable rich, next-generation experiences such as secure payments, specialized sports tracking and precise location monitoring. Data collection is only the first step for these products. The real "user experience" is often the result of a complex mesh of interactions between wearables, smartphones, cloud-hosted array of web applications and analytics software. Designing and validating security for such ecosystems, the kind of which never existed until a few years ago, demands brand-new lines of thinking and security best practices. Wearables live and operate on the human body, collecting a wealth of personal data. This gives rise to new challenges in storing such data securely and conforming to privacy regulations, especially in a world where consumer privacy laws are so diverse.
The Oakley Radar Pace is a head-worn real time, voice-activated coaching system that creates and manages training programs for track running or cycling. The "coach" is an NLP-powered voice assistant on the eyewear. User can converse with it hands-free, and get advanced feedback on their performance.
In our presentation, we talk about the security and privacy research that went into designing and developing Radar Pace, including a custom Security Development Lifecycle (SDL) that accounted for the three "branches" of the program: wearable, phone and the cloud. We present examples of vulnerabilities and privacy problems associated with such new classes of products. While the applications and use cases for wearables are limited only by the designers' imagination, the best practices we have pioneered will be useful and can easily be reapplied by vendors creating new wearables and IoT products. The goal of our presentation is to educate attendees about shedding the old notions of privacy and Security Development Lifecycle when preparing for the products of the future, as well as to discuss interesting security vulnerabilities in such technologies
Millions of networks are relying on Windows authentication protocols to secure their logins, and consequently, their network's integrity. In this talk, we will show a surprising chosen-plaintext attack exploiting a logical vulnerability in one of Windows' more common protocols. The vulnerability affects a wide array of applications including Microsoft Remote Desktop. The attack enables remote code execution and, while being mathematically and technically complex, is very easy to utilize and has nearly 100% of success.
The talk will include a live demonstration of the attack along with a rich description of the technical vulnerability details.
Protection mechanisms running in the kernel-level (Ring 0) cannot completely prevent security threats such as rootkits and kernel exploits because the threats can subvert the protections with the same privileges. This means protections need to be provided with higher privileges (Ring -1). Because of this need, we presented lightweight hypervisor-based kernel protector, "Shadow-box v1" at Black Hat Asia 2017.
However, Linux kernel is used for not only PCs' servers but also mobile devices, IoT (Internet of Things) devices. Mobile and IoT devices typically use ARM-based processors. In the fields of mobile processors, Qualcomm and Samsung play a pivotal role and their trusted execution environment (TEE) such as KNOX, QSEE play also a leading role. Unfortunately, their TEEs are not open technology, so they cannot be used for other ARM-based processors which are normally used for IoT such as Broadcom, NXP, Allwinner, etc.
In this talk, we propose a security monitoring framework for operating systems, Shadow-box v2, using virtualization technologies of x86 and ARM processor. Shadow-box v2 inherits a novel architecture inspired by a shadow play from Shadow-box v1, and we made Shadow-box v2 from scratch. Shadow-box v2 for ARM utilizes OP-TEE (Open Platform Trusted Execution Environment) which follows GlobalPlatform TEE system architecture specification. Qualcomm and Samsung also follow the specification. Moreover, OP-TEE supports more than eleven manufacturers including Broadcom and NXP, therefore Shadow-box v2 can be ported many ARM-based devices easily. Shadow-box v2 also utilizes integrity measurement architecture (IMA). IMA can verify signatures of executable files from kernel. Therefore Shadow-box v2 provides strict integrity of executable files. Shadow-box v2 has additional features such as hash-based kernel integrity monitor, workload-concerned monitoring, and remote attestation in comparison with Shadow-box v1.
We will show a demo of Shadow-box v2 and share our know-how about implementing the kernel protector for multi-platform.
Since the early days of Black Hat Asia, you've always had a NOC, but maybe you never knew it. It's a place where a small team of hackers and geeks do their best to design, stabilize, and dare we say "secure" the Black Hat network infrastructure, and this year, for the first time in Asia, it's open to the public. This talk will cover everything that goes on behind the scenes at Black Hat to get the network put together for each show. We'll share information on current, and previous, designs; and stories about what we've seen or experienced at different Black Hat shows around the globe.
The security of the IoT has never been so important, especially when millions of devices become parts of everyday life. Most of the IoT devices, however, are vulnerable to cyberattacks, as the hardware resources are limited or the security design is missing during the development. Tencent Anti-Virus Laboratory demonstrates a new worm prototype dubbed UbootKit, which targets the bootloader of IoT devices, to indicate how a worm can propagate between variable devices and why it is difficult to eliminate.
UbootKit attack is a kind of manipulation attack against the bootloader, causing infected devices to be remotely controlled and spread malware to other devices. UbootKit is extremely difficult to remove, even by physically pressing the reset button, and is able to attack various kinds of IoT devices with Linux system.
A demonstration will be introduced to explain how UbootKit is able to propagate between ARM and MIPS based devices. First, the worm rewrites the bootloader to parasite on the host. Second, the modified bootloader hijacks the start procedure of the Linux kernel in memory. The malicious code in the kernel will download a worm program and execute it with the root privilege. Finally, the downloaded worm program attacks other devices through password scanning or remote execution exploits. The experiment affirms that UbootKit is able to infect real IoT products, such as routers and webcams. Just to clarify, all experiments were restricted in the laboratory environment, and no harmful payload has ever been applied.
The reason the UbootKit attack can be launched is that the integrity verification for bootloader is missing for most IoT devices. At the end of the paper, a mitigation solution - which is adding an integrity verification procedure at the on-chip code - is explained to address the vulnerability.
Starting from Android 4.3, Android employs SEAndroid (SELinux in Android) to enforce mandatory access control (MAC) over all processes, thus is capable of enhancing Android security by confining privileged processes. However, the effectiveness of SEAndroid enforcement depends on the employed policies.
Unfortunately, policy development is error prone and requires lengthy refinement using audit logs from deployed systems. So, in practice, policy engineers always craft over-permissive rules, which significantly increase the attack surfaces and even lead to real-world privilege escalation attacks.
In this talk, we present a new policy analysis tool, VSPMiner, to detect vulnerable SEAndroid policies in the wild through supervised machine learning. Particularly, we construct the training set via differential analysis and optimize the classification of VSPMiner by leveraging several basic classifiers, i.e., GDBT
, XGBoost and random forests. The cross validation performed on the training set shows that VSPMiner is very promising, e.g., the mean value of F1-score and AUC are above 0.98 and 0.99 respectively.
We evaluate VSPMiner on the policy rules belonging to more than 2000 images with different tuple information (brand, model, android version), that cover the 22 most popular vendors. As a result, we successfully find as many as 132,702 "vulnerable" policy rules, and in which 2,832 problem access patterns (object, permission) are first revealed. In addition to revealing new attack surfaces, we also demonstrate how to abuse the vulnerable policy rules to facilitate Android rooting.
In this talk, we will show that despite all doubts, it is practical to implement malware inside SGX. Moreover, this malware uses the protection features of SGX to hide itself from all state-of-the-art detection mechanisms. We show that an unprivileged user can execute malware inside an SGX enclave that uses a cache attack to extract a secret RSA key from a co-located enclave. Our malware does not use any kernel component, privileges, or operating system modifications to proxy commands from the enclave. Instead, we built novel techniques to mount the attack without operating system support. For a code reviewer, our enclave code looks like a benign series of simple memory accesses and loops.
We demonstrate that this attack is practical by mounting a cross-enclave attack to recover a full 4096-bit RSA key used in a secure signature process. This scenario can be found in real-world situations for Bitcoin wallets that are implemented inside SGX to protect the private key. With an SGX enclave, existing detection techniques (Herath and Fogh, BlackHat USA 2015) are not applicable anymore. The main takeaway is that SGX helps attackers in hiding their malware, without even requiring any privileges (i.e., no root privileges).
Additionally, so-called double fetch bugs are problems in APIs which can often be exploited to hijack the program flow inside a higher-privileged domain, such as given by the enclave. We show that cache attacks can be used to dynamically detect such vulnerabilities in secure enclaves without access to its code or even the binary.
Furthermore, the cache can be used as a primitive to reliably exploit such vulnerabilities, allowing to leak secrets such as private keys from enclaves. In our live demonstration, we show that SGX is not a miracle cure for badly written software and high-quality software is still required to protect secret information.
Code disclosure-guided ROP such as Just-in-time (JIT) ROP and Hacking Blind is popular because of its convenience and robust changes to binary layout. Its increasing popularity leads to several lines of research on the defensive side. Among them, eXecutable-Only Memory (XOM) is one of the most sought-after features, since code read capability is eliminated. XOM could be achieved efficiently in different ways with hardware assist, such as using CPUs that have single layer split-cache (ITLB and DTLB) architecture, using CPUs with Extended Page Table (EPT). However, neither of the techniques are easily deployable for end users, since they have limited control over the target systems. For instance, although modern CPU models still have split-cache architecture, it has been added with an extra layer of unified TLB. Thus, OS will not get information of ITLB miss or DTLB miss. Without that, it is impossible to know whether a page fault is due to code read or instruction fetch. On the other hand, since EPT is managed by hypervisor, it may not be accessible or controllable by end users, especially in cloud. Thus, it is unlikely that end users could use EPT to enforce XOM. By contrast, Memory Protection Keys for Userspace (PKU) is a user-level feature that allows executable pages to be inaccessible from data accesses, without prevention of its execution. PKU has been enabled since Linux kernel 4.9 with the support of XOM; however, there is no end-to-end enabling for applications due the absence of runtime support.
In this talk, we present XOM-switch, a security tool that allows end users to enable XOM on their deployed Linux applications using PKU, a CPU feature that will be widely available in PC market. In our approach, we provide an end-to-end enabling for applications in Linux without source code or heavyweight binary rewriting. We will present the entire pipeline of XOM enabling process in details with all secret sauces to overcome challenges in ELF binaries.
XOM-switch will be demonstrated, showing that it works on real-world, large and complex programs (executables and all dependent libraries) correctly, with almost no performance overhead. XOM-switch will be released with every tool that we have built - including the original source code and the related test data - to enable researchers to replicate the research and to help developers quickly turn on these features without refactoring their code.
