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:
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.
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 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.
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.
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.
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.
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.
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.