Scala is an increasingly popular language that runs on the JVM. LiftWeb and Play are the two main web application frameworks developed for Scala. The language is getting really hot in the web start-up and Financial Tech world, but nobody has dug deep into the frameworks to see if they're secure. This talk reviews the various exploitation mitigations built into each framework and what this means for attackers and defenders. The core of our talk examines the OWASP Top 10 as it applies to Lift/Play and we'll also publicly release our "hack me" app as well a Scala library to help prevent SSRF.
Many point-of-sale breaches occurred in the past year and many organizations are still vulnerable against the simplest exploits. In this presentation, I explain about how points-of-sale get compromised from both a retailer's and a software-vendor's perspective. One of the most common threats is memory scraping, which is a difficult issue to solve. Hence, I would like to share with you a demonstration of how it works and what can be done in order to minimize this threat. During this presentation, I will explain the long journey it took me to understand how to mitigate it, while walking through the concepts (not exposing vendor names) that don't work and those that can work.
The secure BYOD hype is growing and Virtual Desktop Infrastructure (VDI) is considered the alternative solution for secure containers. In a nutshell, VDI solutions provide a remote workstation offering so that no data is stored locally. We decided to examine the architecture and see for ourselves whether VDI delivers on its security promise.
In this engaging session, we demonstrate a proof-of-concept attack where a malicious app leverages screen scraping to exfiltrate data through common VDI platforms. By simulating the user's interaction, we show how such an attack is not only feasible - but also efficient. While keeping the espionage activity invisible both from client-side and server-side malware detection measures, the attacker can automate the process and ultimately render the VDI solution ineffective.
Software Defined Networking (SDN) transfers all forwarding decisions to a single controller and provides the network with the same degree of control and flexibility as the cloud. And, with all the major vendors onboard, it will soon be supporting networks everywhere. But, current implementations are full of weaknesses that could easily turn this utopian dream of the future into a nightmare and leave networks world-wide exposed.
With clear-text wire protocol implementations, little support for switch TLS, no authentication for nodes, poorly conceived rate-limiting features in the controllers, controller APIs that don't require authentication, and back-door netconf access, the leading platforms Floodlight and OpenDaylight, are ripe for attack.
And in this session, using a new toolkit that I developed, I'll demonstrate by showing you how to locate and identify these controllers, impersonate switches to DoS them, and engage their wide-open APIs and backdoors to map the network, locate targets, and control access to the network...even hide from sensors. But all is not lost, because I'll show how to protect them too. Because dream or nightmare, SDN can make a difference in the real world if we just protect it right.
In 2013, MITRE released Copernicus 1, a best-effort system to capture a raw dump of the BIOS and whether it appears to be possible for an attacker to write to it. In 2014, we released Copernicus 2 to combat the ability of an attacker to subvert not just Copernicus 1, but all other BIOS capture systems. While these free tools are a good way to get a copy of your BIOS, analyzing it to detect malicious changes is still an open problem in need of further investigation before defenders can feel confident that they have un-infected BIOS. You can't just compare the MD5s from two BIOS dumps and get a valid comparison. This is a problem that leads to firmware-level malware going under-reported and under-analyzed due to not enough people with the background to jump into this area.
In this presentation, we will assume that you have a suspected badBIOS dumped by Copernicus that you'd like to determine the integrity and authenticity of. We will perform a breadth-first discussion of the topics such as port IO, memory-mapped IO, PCI, SMM, UEFI, and others that you need to become more familiar with in order to effectively analyze modern BIOSes. We will especially focus on how UEFI's removal of security through obscurity is a double edged sword which helps both attackers and defenders analyze BIOSes for attacks or integrity checks. This talk will serve as a gateway for people with existing reverse engineering knowledge to start analyzing modern PC firmware.
Android is a pliable environment bent into different shapes by different OEMs. While Android offers several security mechanisms at the framework and at the application levels, there's little it offers to an OEM that customizes Android. We have seen vulnerabilities in Android stemming out of excess file permissions, processes left running as root or system after a debug cycle, privileged security capabilities in an attempt to avoid setuid files, and so on. While there are tools to run partial checks at either the Android framework level or at the Linux layer, we do not have a powerful tool that can scan for platform level vulnerabilities. We announce our tool called Iron Crow that can greatly benefit Android BSP developers and OEMs to catch vulnerabilities of this nature - thereby protecting end users, improving the security of Android, and also protect themselves from media reprimand.
APTs and government-supported attackers use a broad arsenal of techniques to avoid having their exploits detected by IDSes. Signature Based IDSes are not efficient against nation-state-sponsored attackers which use custom shellcode encoders in an exploit. Emulation Based NIDSes (EBNIDS) have been proposed as a solution to mitigate such attacks. EBNISes detect a suspicious network stream (pre-processing) and after converting them to emulate-able byte sequences run it in an instrumented environment (Emulation), finally matching the behavior with certain heuristics (Heuristics Detection). In this talk, we will present novel ways that an APT might use to circumvente the Pre-Processing, Emulation and Heuristic Detection steps of EBNIDSes by employing a wide range of evasion techniques.
Android is the most prevalent Linux-based mobile Operating System in the market today. Many features of the platform security (such as stack protection, key generation, etc.) are based on values provided by the Linux Pseudorandom Number Generator (LPRNG) and weaknesses in the LPRNG could therefore directly affect platform security. Much literature has been published previously investigating and detailing such weaknesses in the LPRNG. We build upon this prior work and show that - given a leak of a random value extracted from the LPRNG - a practical, inexpensive attack against the LPRNG internal state in early boot is feasible. Furthermore, the version of the Linux kernel vulnerable to such an attack is used in the majority of Android-based mobile devices in circulation. We also present two real-world exploitation vectors that could be enabled by such an attack. Finally, we mention current mitigations and highlight lessons that can be learned in respect to the design and use of future PRNGs for security features on embedded platforms.
With the increasing interests in virtualization, there is a rapid development in virtualization-based security monitoring products. Most of the products have an assumption that the hypervisor is trusted. However, the assumption is invalid when the boot process is intercepted. In this talk, we discuss the boot process of Xen and how it can be manipulated via proof-of-concept bootkits. Xen can boot via BIOS or UEFI. In the first case, Grub is needed as a middleware. However, both of the two boot processes can be manipulated. Booting from the combination of BIOS and Grub can be attacked by rewriting boot sectors and booting from UEFI can be attacked by replacing EFI file. At last, we will give two examples to attack Xen-4.2.2 for these two situations. The Grub version is Grub-2.0.0. Both of the two examples can get control before the initialization of Xen and obtain the privilege of the hypervisor. They only leave some 64-bit codes for patching in the memory.
It is well known there is a race going on in the "Big Data" arena (take a drink for even thinking about the "Internet of Things"). One of the stronger competitors in the "Big Data" market is Real-Time, In-Memory Platforms. An interesting thing about this platform and, the one we will talk about specifically, is that it blends everything to increase performance. The database tables, webserver engine, webserver code, authorization, analytics engine, libraries, etc. are all optimized to, if possible, never touch the disk.
Surprisingly, this causes a perspective shift for the web and database application threat landscape and how security professionals should address it. For example:
Amazon Web Services (AWS) is billed as an amazingly secure and resilient cloud services provider, but what is the reality once you look past that pristine environment and the manicured forests give way to dark jungle as you start to migrate existing applications to the AWS Cloud or design new ones for AWS exclusively?
In this talk, we will explore Amazon Web Services and the advent of "full stack" vulnerabilities and how they create new security pitfalls when migrating to and operating in an AWS world. From the unexpected to the unintended, many examples will be shared along side new techniques showing how you have likely already exposed your applications and infrastructure to attack through misunderstanding, ignorance, or bad actors.
To address these challenges, this presentation will also reveal and demonstrate a free tool we have designed to assess AWS applications, map out the interactions between infrastructure and code, and help individuals and organizations get clarity and bring a machete to the Amazon Cloud.
For the last few years, some different attacks against SSL/TLS have been released. Some of them based on cryptography or protocol weaknesses such as BEAST, CRIME, etc, and some others, such as SSLStrip, based on rewriting https links into http ones and keep user communications always in HTTP. In order to protect users against SSLStrip attacks, a new protection called HTTP Strict Transport Security (HSTS) has been developed and it's currently supported by most widely used browsers.
However, under certain circumstances, an attacker could exploit an inter-operation vulnerability in order to bypass HTTP Strict Transport Security protection and use other well-known attack techniques such as SSLStrip. In this presentation, we review the HSTS strengths and weaknesses, and we go in-depth on this inter-operation vulnerability and how it could be exploited.
The C++ language and its siblings like C and Objective-C are ones of the most used languages today. Significant portions of operating systems like Windows, Linux, Mac OS X, iOS and Android are written in C and C++. There is however a fact that is little known about C++: it contains a Turing-complete sub-language executed at compile time. It is called C++ template metaprogramming (not to be confounded with the C preprocessor and macros) and is close to functional programming.
During this talk, I will show how to use this language to generate, at compile time, obfuscated code without using any external tool and without modifying the compiler. The techniques presented rely only on C++11, as standardized by ISO. I will also show how to introduce some form of randomness to generate polymorphic code and I will give some concrete examples like the encryption of strings literals or the obfuscation of calls using finite state machines generated at compile time.
All the examples presented will be released under GitHub.
Since the introduction of the smart phone, the issue of control has entered a new paradigm. Manufacturers and enterprises have claimed control over not just how your phone operates, but the software that is allowed to run on it. However, few people know that service providers have a hidden and pervasive level of control over your device. These hidden controls can be found in over 2 billion cellular devices worldwide. Organizations have been quietly deploying these controls in smart phones, feature phones, basebands, laptops, embedded M2M devices, and even certain cars. Someone with knowledge of these controls and the right techniques could potentially leverage them for cellular exploitation on a global scale.
We've reverse engineered embedded baseband and application space code. We've torn apart the Over-the-Air communications and implemented our own code to speak the relevant protocols. Layer by layer, we've deconstructed these hidden controls to learn how they work. While performing this work, we've unearthed subtle flaws in how the communication is handled and implemented. After understanding these flaws, we've written proof-of-concept exploits to demonstrate the true risk this software presents to the end user.
In this presentation, we will discuss and disclose how Over-the-Air code execution can be obtained on the major cellular platforms and networks (GSM/CDMA/LTE). Including but not limited to Android, iOS, Blackberry, and embedded M2M devices. You will come away from this talk armed with detailed insight into these hidden control mechanisms as well as the tools to help assess and protect from the new threats this hidden attack surface presents. These tools will include the ability to dynamically test proprietary system applications and simulate different aspects of a cellular environment.
I'll expose USB vulnerability in some vendor's customization of the Android system, I'll also target that vulnerability in a specific vendor, together with a proof of concept of the attack and practical scenario environment, and I will unveil the implications of such vulnerability. Culminating in the flashing of a compromised boot partition, and root access.
Successful dynamic analysis of malware is dependent on your ability to "Fake the Network." Tricking malware into thinking it is connected to the Internet allows you to efficiently capture network signatures. FakeNet is a free and easy-to-use network simulation tool designed for Windows. In this workshop, we will publically release FakeNet 2.0 and teach you how it operates.
Attendees will learn the following practical skills:
- Use FakeNet to mimic common protocols like HTTP, SSL, and DNS
- Quickly reconfigure FakeNet to have success defeating malware
- How FakeNet uses Windows Internals
- Use process tracking, which allows you to quickly identify the process responsible for the malicious network activity
- How FakeNet automatically logs network traffic to PCAP without the need for additional tools
Bring your Windows malware analysis Virtual Machine or we'll provide one for you. The hands-on section of this workshop forces you to analyze real world malware samples to tease out network-based malware signatures. These challenges start at a basic level and progress until you dive into how to extend FakeNet by writing a Python Extension for a custom malware protocol.
The Universal Serial Bus (USB) has become the standard interface for interconnecting computers with peripheral hardware today. USB is used to access human interface devices (HID) like keyboards and mice, storage devices like USB flash sticks or external harddrives but also webcams, soundcards, network cards (NIC), wireless cards, and bluetooth sticks etc. While the most common devices like keyboards, mice, and storage devices are handled via generic drivers by the kernel on the host system, many devices require specific drivers. Using the facedancer device created by Travis Goodspeed and Sergey Bratus, many implementation bugs in the generic drivers have been found. Systematic analysis of the hardware specific drivers using fuzzing based on the facedancer device is almost impossible because of the enormous amount of different devices and drivers. The current Linux kernel supports 15,000 different vendor and product ids which are mapped to several hundred drivers. These drivers might behave differently depending on the vendor/product id presented. One basic USB simulated test using the facedancer requires 2-7 seconds execution time and can only be parallized using several facedancer devices and as many physical hosts.
Therefore, I developed the vUSBf framework. This framework implements a virtual USB fuzzer based on KVM and the USB redirection protocol in QEMU. It virtualizes the target systems and using parallization we are able to execute up to 150 tests/second on a single Intel system with 24 cores. Using the built-in cluster protocol, we are able to arbitrarily scale this using additional systems.
The vUSBf framework allows the dynamic definition of several million testcases using a simple XML configuration. Each test is identified using a unique test id and thus is reproducible.
We are triggering and detecting the following bugs in both Enterprise Linux kernels and the most current Linux kernels:
- Null-pointer dereferences
- Kernel paging requests
- Kernel panic
- Bad page state
While the actual exploitation of these bugs still needs to be tested and their severity to be determined, the vast amount of bugs we are finding, is frightening. About 0.3% of the tests trigger one of the above listed exceptions in the Linux kernels depending on the kernel used and the amount of drivers included.
To validate the results some of the bugs were reproduced using the facedancer and physical hosts. This proves that these bugs might be reproduced using specialized hardware which than can attack, exploit, and maybe compromise the target system.
The vUSBf framework uses several emulators for the fuzzing of different devices and stages of the usb connection. Further emulators can be added via a simple API and are currently in development. Additionally, first tests have been executed using Microsoft Windows as a target.
The framework will be released as Open Source at the Black Hat Conference.
Today, industrial control system architectures are complex, multilayered networks, based on many popular (now and not so long ago) technologies, such as XML, COM, ActiveX, OLE32, JSON, .Net, and others. FDT/DTM is one of such architectural elements. In short, FDT/DTM standardizes the communication and configuration interface between all (industrial) field devices and host systems. This is archived with the help of DTM - COM, ActiveX or .Net components. Such components exist for many devices used in oil, gas, energy, nuclear, chemical, and other critical industries. Look at any factory, plant, or other industry object, and you'll find an RTU or PLC that is configured by a DTM component.
During our research, we've analyzed the components for hundreds of field devices based on the Modbus, HART, and Profibus DP low-level protocols. Many of them are exposed to insufficient filtration of user-supplied data, XSS, XXE, SSRF, DoS, and other vulnerabilities. We will provide detailed statistics on the security flaws of DTM components from various vendors.
The Internet is no longer trustworthy, having been compromised by bad actors across the globe. Current proposals to work around a compromised Internet rely upon encrypted transport links, mesh networks, or harassing users for being unable to use GPG safely. Each of these strategies fails in different ways that inevitably lead to information leakage or - in the extreme case - death. Endrun, by contrast, takes NASA's Disruption-Tolerant Networking project from a laboratory experiment to a functional system that supports user-friendly encryption in hostile environments. Endrun embraces the nearly-unlimited throughput of a disk-laden station wagon and creates a reliable, eventually-consistent communications system ideal for activists, refugees, and trolls.
The forthcoming depletion of IPv6 addresses is now closer than ever. For instance, ARIN states that they are currently in phase three of a 4-phased "IPv4 Countdown Plan," being already down to about 0.9/8s in aggregate. On the other hand, RIPE NCC has reached its last /8 IPv4 address space quite some time ago. Moreover, the nodes of the networks (end-hosts, networking devices, security devices, etc.) are already pre-configured with IPv6 connectivity, at least to some extent. Furthermore, in your LAN environment if you use one of the latest popular Operating Systems, from Windows 7 to Linux or FreeBSD, IPv6 messages are being sent while the hosts are reachable by using at least link-local address. So, IPv6 is finally here even if you haven't realised it and it is definitely going to stay.
And what IPv6 does not forgive for sure is the lack of security awareness. IPv6 is not IPv4 with just extended address space. Several times in the past it has been shown that this "new" layer-3 protocol, apart from the huge address space and other new functionalities, it also brings with it several security issues. In this paper, it will be shown that significant security issues still remain unsolved. Specifically, four different techniques will be presented and analysed that allow attackers to exploit even a really minor detail in the design of the IPv6 protocol to make security devices like high-end commercial IDPS devices or popular open-source solutions completely blind. These techniques allow the attackers to launch any kind of attack against their targets, from port scanning to SQLi, while remaining undetected. Moreover, in this talk, after presenting detailed analysis of the attacks and the corresponding exploitation results against IDPS devices, potential security implications to other security devices, like firewalls will also be examined. Finally, specific mitigation techniques will be proposed, both short-term and long-term ones, in order to protect your network from them.
Mac OS X 10.10 Yosemite is going to be released soon. It brings lots of new features as well as security improvements. In the first part of the talk, we are going to review these improvements from both defensive and offensive perspectives: what problems it solved, what issues it brought up, and what tricks still work.
In the second part, we will try several ways to abuse Mac OS X 10.10, and show you running malware and even rootkit is not a problem. A number of new offensive techniques will be introduced, including kernel mode and user mode, for example, loading a unsigned kernel module without warnings, manipulating kernel objects (rootkit) to evade detection, very stealthy techniques to launch malware, etc. All of the tricks were tested on Mac OS X 10.10.
Not only the offensive side, we are going to release a security tool in this talk as well. A comprehensive rootkit and abnormality scanner, we call it SVV-X (System Virginity Verifier for Mac OS X, including 10.10). The tool covers not only basic checks, such as hooks on syscall table, mach trap, IDT table, critical data verification, kernel code integrity, and it also checks many user mode tricks.
As embedded systems are more than ever present in our society, their security is becoming an increasingly important issue. However, with many recent analysis of individual firmware images, embedded systems acquired a reputation of being very insecure. However, we still lack a global understanding of embedded systems security as well as the tools and techniques needed to support such general claims.
In this talk, we present the first public, large scale, analysis of firmware images: we unpacked 32K firmware images into 1.7M individual files, which we then analyze. We leverage this large scale analysis to bring new insights and outline several open challenges when performing such experiments. We also show the main benefits of looking at many different devices at the same time and of linking our results with other large scale datasets, such as the ZMap SSL collection. We discuss results that would not have been possible to achieve without such a wide-scale analysis.
In summary, without performing sophisticated static analysis, we discovered a total of 38 previously unknown vulnerabilities in over 693 firmware images. Moreover, by correlating similar files inside apparently unrelated firmware images, we were able to extend some of those vulnerabilities to over 123 different products. We also confirmed that some of these vulnerabilities altogether are affecting at least 140K devices accessible on the public Internet.
We believe that this project, which we plan to provide as a service on the long term, will help shed some light on the security of embedded devices.
We propose a set of techniques for "freeze drying" malware and restoring the captured malware to enable live process migration. Our system can capture environment-sensitive malware in-process and run it in an environment other than the infected host.
Sophisticated malware, such as Citadel and ZeuS/GameOver, are armed with anti-analysis techniques to prevent running except on an infected host. These malwares detect the execution environment and do not engage in malicious behavior when the current host differs from the infected host.
We developed a malware capture system called Sweetspot that can capture malware in-process by using process live migration and mimicking the infected host's environment on the analyzer by means of system call proxies. In addition, Sweetspot can serve as a honeypot and provide dummy data when the malware requests sensitive information. In briefings, we will demonstrate freeze-drying and instant dynamic analysis of real malware.
We show that the gyroscopes found on most smart phones are sensitive to measure acoustic signals in the vicinity of the phone. Since iOS and Android require no special permissions to access the gyro, our research shows that apps and active websites that cannot access the microphone can nevertheless eavesdrop on speech in the vicinity of the phone. We have validated our findings on numerous phones and tablets with different gyro models. This is a joint work with Dan Boneh of Stanford University.
At all times there have been bad guys, who tried to steal money. ATM machines containing vast amounts of money have always been attractive targets. Until recently, criminals were only using physical weaknesses. Skimmers and shimmers for stealing magstripe-tracking data, fake pin pads and cameras for stealing pin codes, and even fake ATMs were created.
Time passed and ATM software started to unify. Where there is unification, there are viruses. Trojan.Skimmer.*, Ploutus and other named or unnamed trojans.
And what did we see on the public scene? Vendors started discussing the skimmers problem only after they were detected in the wild. As you remember, Barnaby Jack presented "Jackpotting Automated Teller Machines" at Black Hat USA 2010. He used some vulnerabilities in ATM software. He showed that malware, was injected into the OS of the ATM via bootable flash drive or via remote management TCP port.
Barnaby Jack's work was based on assumptions that most vulnerabilities were concentrated in the host machine and that we can and should reuse software made by ATM vendors. And that's quite true, but... antiviruses, locked firmware upgrades, blocked USB connectors, and encrypted hard drives can mitigate such risks. But, what about connecting not to the host machine, but to devices themselves? What countermeasures exist, when we will try to impersonate ourselves as an ATM host? Hacking ATMs with small computer like Raspberry Pi should be impossible, but it isn't.
The point of our presentation is to draw attention to the problem, which has existed for quite a long time. The problem is usage of common interfaces (like RS232 or USB) and protocols of communication from host machine to such devices as card readers, pin pads and/or dispenser units.
Ever wanted to communicate with a NASA space probe launched in 1978, or spoof a restaurant's pager system? There are surprising similarities! How about use an airport's Primary Surveillance RADAR to build your own bistatic RADAR system and track moving objects? What sorts of RF transactions take place in RFID systems, such as toll booths, building security and vehicular keyless entry? Then there's 'printing' steganographic images onto the radio spectrum...
Wireless systems, and their radio signals, are everywhere: consumer, corporate, government, amateur - widely deployed and often vulnerable. If you have ever wondered what sort of information is buzzing around you, this talk will introduce how you can dominate the RF spectrum by 'blindly' analysing any signal, and then begin reverse engineering it from the physical layer up. I will demonstrate how these techniques can be applied to dissect and hack RF communications systems, such as those above, using open source software and cheap radio hardware. In addition, I'll show how long-term radio data gathering can be used to crack poorly-implemented encryption schemes, such as the Radio Data Service's Traffic Message Channel.
I'll also look briefly at some other systems that are close to my heart: reversing satellite communications, tracking aircraft using Mode S and visualising local airspace in real-time on a 3D map, monitoring the health of aircraft with ACARS (how many faults have been reported by the next plane you'll be travelling on, e.g. do the toilets work?), and hunting down the source of an interfering clandestine radio transmission.
If you have any SDR equipment, bring it along!
Many companies are getting Hadoopy often with little or no consideration of security because Big Data is on their list of cool projects. Have they opened the door to compromise? Better predictions and more intelligent decisions are expected from our biggest data sets, yet can we really trust the systems we secure the least? And is anyone ready to face why our best "learning" machines continue to make amusing and sometimes tragic mistakes? Infosec is in this game but Big Data is moving at a pace faster than our controls are being considered. What have we done about emerging vulnerabilities and threats to Hadoop as it leaves many of our traditional data paradigms behind? This presentation, based on the new book "Realities of Big Data Security" takes the audience through seven simple ways to deal with serious risks and elephantine security challenges here today.
Malware authors are always interested in concealing their goals to evade detection.
We have discovered a technique which enables them to hide whatever payload they wish in an Android package (APK).
The malicious payload is encrypted with AES, thus its reverse engineering does not give in any element.
Moreover, contrary to general belief, it is actually possible to manipulate the output of encryption and have it look like, for instance, a chosen image. Thus, the encrypted malicious payload can be crafted to look like an absolutely genuine image (of Anakin Skywalker ;).
We demonstrate with a Proof of Concept application that the attack works on current Android platforms, and we also explain how it works and how the payload is crafted.
This talk is not (or only very little) about cryptography. Understanding file formats, that's the magic :).
There is a lot of talking about ICS, SCADA and such nowadays, but only few people have the opportunity to get their hands dirty and understand how it works. The goal of this workshop is to provide the knowledge required to start attacking Scada networks and PLCs, and give hands-on experience on real devices.
In this workshop, you will learn the specifics of performing a penetration test on industrial control systems, and especially on Programmable Logic Controllers (PLCs). We will cover the main components and the commonly associated security flaws of industrial control systems, aka SCADA systems. We will discover how they work and how they communicate with the SCADA systems to learn the methods and tools you can use to p*wn them.
Then, we will move on to real-world by attacking a Siemens S7-1200 PLC and a Schneider m340, which are two common PLCs.
Hypervisors have become a key element of both cloud and client computing. It is without doubt that hypervisors are going to be commonplace in future devices, and play an important role in the security industry. In this presentation, we discuss in detail the various lessons learnt whilst building and breaking various common hypervisors. In particular, we take a trip down memory lane and examine vulnerabilities found in all the popular hypervisors that have led to breakouts. To add some spice, we will talk about details of four not-yet-discussed vulnerabilities we recently discovered.
One of the key value propositions of hypervisors, as they relate to security, is to shrink the attack surface. However, in the quest for new features and functionality some trade-offs are made, which can prove to be fatal. While discussing the particular problems, we will examine what the strong (and weak) security-related features of hypervisors are. We compare the attack surface of hypervisors with that of user mode applications and operating systems kernels, and show that the purpose and design of the hypervisor significantly changes its attack surface size. Most importantly, we make a fact-based argument that many hypervisors aren't designed with security in mind. We show how superfluous code and poor design can be punished by demonstrating real examples of hypervisor breakouts.
The presentation ends with lessons learnt, and recommendations for hypervisor design and approaches that can be taken to harden them.
We all know that connected devices are uprising, and this enables more overall control over them. But what happens when that control is used against you? How can a device, which is supposed to make your life easier, be used against you? Does it really mean, when you read "AES, Triple DES, RSA, etc..." in a device specification, that it is really secure?
We will talk about a device that is present in all houses, a smart power meter. This model is being installed in all houses and buildings, and it's already present in the 65% of the "paella" country. We will show the process necessary to rip off any device, taking the meter as "demo hardware," and the possibilities that this procedure could bring, including firmware and hardware reverse engineering.
As a small preview, these smart meters are capable of cutting down the power supply by receiving remote commands. Oh, and by default, they are not able to "talk" between them.
Big Brother is watching your droid. His name is Binder.
As the only vehicle of IPC in Android, Binder is the system component that makes the operating system tick. A process running in a typical OS will hold dozens of handles to the system's hardware: hard disk, display adapter, network card, and many more. Android's unique architecture, on the contrary, means that a process will achieve the same tasks just by grabbing a file descriptor to the Binder device - greatly minimizing the attack surface against the kernel. As the god of IPC in Android, Binder controls an application's interaction with just about anything.
From that perspective, it becomes immediately apparent that this system component is a prime target for any Android malware. By controlling any single link in the long chain which leads down from the Java APIs to the native Binder code, an attacker could stealthily implement a keylogger, set up VNC-like functionality, modify sensitive data in transit, and do many other evil deeds.
In this presentation, we will showcase a POC rootkit which provides a basis for all of the above, and more. We will also give a comprehensive overview of Binder at the lowest level. We'll talk about how the data transport buffers are actually constructed, what gets sent down to the kernel, and what comes back up. We believe this is an important contribution to the security community: Binder has simply not been researched enough.
Through extensive analysis, ISE has identified dozens of previously undisclosed, critical security vulnerabilities in numerous network storage devices from a handful of goto manufacturers (manufacturers: e.g., Seagate, D-Link, Netgear). Vulnerabilities of network-attached storage not only expose stored data, but also provide a vantage point for further PWNAGE of the network infrastructure on which the storage system sits. Our research efforts focused on identifying vulnerabilities that obtained administrative access (such as command injection, directory traversal, authentication bypass, memory corruption, backdoors, etc.), and quantifying the associated risk.
The attacks we developed demonstrate how unauthenticated attackers can compromise and control storage systems with and without user interaction.
Network based storage systems are used in millions of homes, schools, government agencies, and businesses around the world for data storage and retrieval. With today's dependence on Internet based services, virtualization technologies, and the need to access data from anywhere, storage systems are relied on more than ever. Similar to other network hardware (e.g., routers), these devices are purchased and installed by IT teams and home consumers with the expectation that the system is protected from the infamous hacker.
This presentation focuses on "how to," and the implications of compromising network based storage systems, but will conclude that the absence of security in not only storage hardware, but networking hardware in general, has left data unprotected and millions of networks vulnerable to exploitation.
Throughout this presentation, several vulnerabilities will be exploited in order to achieve the glorious ro0t (#) shell! This presentation will also showcase a self-propagating worm that is capable of exploiting network storage systems on both internal and external networks!
Cheaters are a growing problem in multiplayer gaming. As games become increasingly complex, the level of sophistication in cheat detection and anti-cheating strategy is forced to keep pace. While some developers spend the time to create their own protections, many have turned to external anti-cheat libraries. These tools are managed by a central server and offer an ideal target for attackers. We outline two practical attacks against one of the most popular anti-cheat engines and demonstrate the implications of a successful attack against anti-cheat software.
In recent years, the idea of collecting and analyzing data about a subject has transitioned and the subject is now the person. We are not just talking about high level details about the person but instead we are dealing with highly detailed and personal information at a low-level. A new term has been coined for this activity and it is generally known as the concept of the Quantified Self (QS). This trend is a collision of several different forces currently observed, including wearable smart devices, the Internet-of-Things, and social media.
QS is about personal data, but not as we have known it. While analyzing the top QS apps for smartphones we have found all sorts of worrisome behavior. How much data is actually gathered? How is the data stored? How many entities do you have to trust to not sell your data to marketing companies? These are only a few of the questions that users have to ask themselves. We will explain the different attack vectors and attack scenarios against QS devices.
Furthermore, we discovered that most of the quantifying self hardware devices, like sports bracelets, do not implement the full spectrum of privacy functions available. Hence, people using such activity trackers can be tracked by others. We created a proof of concept scanner and performed some tests in different European cities. We will discuss the scan results and show that when the tracking is combined with the leakage of personal identifiable information, this can quickly become a nightmare.
Quantum computing will bring tumultuous change to the world of information security in the coming decade. As multi-qubit systems use quantum algorithms to slice through even 4096-bit PK encryption in seconds, new Quantum Encryption will be required to ensure data security. Join Konstantinos for a look at real world experiments in Quantum Key Distribution that BT and partners have recently performed that show what the future of encryption will look like. Remember the panic after Heartbleed when SOME passwords needed to be changed? Imagine a day when ALL communications are at risk of eavesdropping via Quantum Computers - a day when only new systems that exploit the weirdness of quantum mechanics can ensure privacy.
Attackers would LOVE having the ability to upload executable files to domains like Google.com, Facebook.com, and Bing.com. How cool would it be for them if their files are downloaded without ever being uploaded! Yes, download without upload! RFD is a new web based attack that extends reflected attacks beyond the context of the web browser. Attackers can build malicious URLs which once accessed, download files, and store them with any desired extension, giving a new malicious meaning to reflected input, even if it is properly encoded. Moreover, this attack allows running shell commands on the victim's computer.
How bad is it? By using this attack on Google.com, Bing.com and others, I created the first cross-social-network worm that is downloadable from trusted sites like Google.com, completely disables same-origin-policy, steals all browser cookies, and spreads itself throughout all social networks such as Facebook, Twitter, Google+, and LinkedIn.
Return-to-user (ret2usr) attacks redirect corrupted kernel pointers to controlled data residing in user space, by taking advantage of the weak separation of the kernel context from user space, as for performance reasons the kernel is typically mapped into the address space of every process. In response to such attacks, several kernel-hardening approaches have been proposed to enforce a more strict address space separation, by preventing arbitrary control flow transfers and dereferences from kernel to user space. Intel and ARM recently introduced hardware support for this purpose in the form of the SMEP, SMAP, and PXN processor features.
In this presentation, we show that although mechanisms like the above prevent the explicit sharing of the virtual address space among user processes and the kernel, conditions of implicit sharing still exist due to fundamental OS design choices that trade stronger isolation for performance. We demonstrate how implicit data sharing can be leveraged for the complete circumvention of software and hardware kernel isolation protections, by introducing a new kernel exploitation technique, dubbed return-to-direct-mapped memory (ret2dir). ret2dir bypasses existing ret2usr protections, such as PaX's KERNEXEC and UDEREF, Intel's SMEP and SMAP, as well as ARM's PXN, by taking advantage of the kernel's direct-mapped physical memory region. We present techniques for constructing ret2dir exploits against x86, x86-64, AArch32, and AArch64 Linux targets that bypass all tested protection mechanisms (KERNEXEC, UDEREF, SMEP, SMAP, and PXN). To mitigate ret2dir attacks, we also discuss the design and implementation of an exclusive page frame ownership scheme for the Linux kernel that prevents the implicit sharing of physical memory pages.
The online WYSIWYG "What You See Is What You Get" editors or rich-text editors are nowadays an essential component of the web applications. They allow users of web applications to edit and enter HTML rich text (i.e., formatted text, images, links and videos etc) inside the web browser window.
This talk will first demonstrate how to break the top 25 online WYSIWYG editors powering thousands of web applications. We show XSS bypasses for top WYSIWYG editors like TinyMCE, Jive, Froala, CKEditor etc. We will share stories of how we were able to XSSed WYSIWYG editors of sites like Twitter, Yahoo Email, Amazon, GitHub, Magento, and CNET etc.
After breaking almost all WYSIWYG editors in the wild, this talk will present a sanitizer (very easy to use, effective and practical solution) which is based only on '11 chars + 3 regular expressions' and will show how it will safe you from an XSS in HTML, attribute, script (includes JSON context), style and URL contexts.
Ever since Cross-site Scripting (XSS) was discovered in the year 2000, one of the main goals of an XSS attack was to take over the victim's session, and, thus his authentication context with the vulnerable web application. Consequently, the terms "XSS" and "Session Hijacking" were used as synonyms for many years. However, the introduction of defensive features, such as HTTPonly Cookies, efficiently prevents the stealing of session IDs and mitigating this class of attacks. However, while session identifiers are protected robustly, another more powerful and much more long-lived authentication credential might not be: The Web user's password.
In consequence, a successful XSS attack can be leveraged by the attacker to read and leak password data which has been provided by the password manager.
In this presentation, we give a comprehensive overview on potential XSS-based attack patterns on browser-provided password managers. In this context, we present two systematic studies:
- For one, we examine the current generation of existing password managers in all (!) major browsers and show their susceptibility to the outlined attacks. We will show in detail how an XSS attack can leak obtain user's password from the manager and leak it to the user.
- Furthermore, we report on a large-scale study on the Alexa Top 4000 site, in which we studied how password fields are used by popular websites.
We will conclude the presentation with a set of recommendations, both for website operators as well as web users, how to protect themselves against the demonstrated attacks.
The "go to fail" bug was a shock for all security-aware apple users. A simple coding error lead to a missing check in SSL validation with grave consequences. Many applications rely on SSL, but only few recognize that all of its helpful mechanisms (encryption, integrity protection, replay protection) are not worth a penny without proper authentication of communication peers. We suspected that many programs, especially mobile apps, do not fully validate the certificate of the server they send confidential information to. Could "go to fail" and similar insufficient certificate validation checks be tested for, without having access to the source code? To test this out, we developed SVF - the "SSL-Validation-Fuzzer" for easier certificate validation check testing in cooperation with University of Applied Sciences St. Poelten. SVF is written in python and based on the well-known mitm proxy software. For testing, it is placed between the test target (e.g mobile app) and the server. SVF will 1.) capture the SSL handshake 2.) generate several mutation certificates based on the original server certificate according to a range of test cases 3.) allow the user to apply those mutation certificates in the encryption in order to 4.) test if the client starts/continues data transfer with a forged certificate, thereby allowing testing of client-side certificate validation logic. Though currently still a simple yet powerful prototype, we used SVF on a bunch of iOS, Android, and Windows Mobile apps. The first range of testing candidates were mobile banking applications, as we expected strong validation checks here. We started with mobile banking apps from our home country Austria, then moved on to banking apps from other countries too, giving us some very interesting results and a glimpse on the state of certificate checks overall. Vendors affected by the discovered vulnerabilities are informed in a coordinated disclosure process. In our talk, both the SVF tool, as well as the results from our field study, will be presented. We believe that although still in a prototype stage with just a bunch of test-cases, SVF-type checks could be valuable not only for app-developers, but anyone trying to test the SSL-validation checks of an app, thereby testing its susceptibility to crafted man-in-the-middle attacks.
The browser, as no one needs to explain, plays a very important role in security. There are many browser fuzzing tools, like cross_fuzz and grinder, which help people to build their own browser fuzzing system.
However, the most important thing of fuzzing is the fuzzing strategy. With a good strategy, we can find more vulnerabilities instead of useless crashes. With a unique strategy, we can find bugs that others couldn't find.
From September 2013 to April 2014, we discovered more than 100 IE use-after-free vulnerabilities. We got 19 CVEs that affect all versions of Microsoft IEs. We also have more than 50 pending IE vulnerabilities at MSRC.
In this talk, we are going to introduce the vulnerability hunting system we built from scratch and the fuzzing strategy we used.
Two Factor Authentication (2FA) systems are required by security standards and help to solve the many weaknesses of password authentication, and are increasingly found both in enterprise systems and in general web applications.
Unfortunately, many 2FA systems have vulnerabilities - some glaring, some more subtle - and 2FA systems have frequently sacrificed security to be more usable.
We will demonstrate the vulnerabilities of various 2FA systems, including a new form of attack against mobile phone based TOTP (RFC 6238) systems, and describe best practices for deploying 2FA of various types.
WebKit is widely used as a web rendering engine by applications present on almost all popular PC platforms including Windows, Mac OS X, as well as mobile platforms such as iOS and Android. Usually a single vulnerability in WebKit - either logic or memory corruption one - utilized with appropriate exploit techniques can result in a remote code execution impacting various applications, regardless of what platforms they are running on.
Difficult, but not impossible.
Despite the strong security, defeating WebKit-based applications is still feasible. In this talk, I will discuss the details of these security enhancements and the approach I took to defeat them. The talk will be illustrated by demos of two exploits. The first one is a Webkit vulnerability deployed using several advanced exploit techniques to deliver a remote code execution that doesn't rely on Heap Spray technique and can be reliably ran on x64 Safari browser. The second one will demonstrate that similar techniques also apply to mobile applications.
At the end of our talk, we will provide recommendations on how to improve security of WebKit-based applications.