Cryptography, social networks, today the use of online tools and serving to protect their communications allows jihadists to affirm their membership in jihadist movements. Studies of the Middle East Media Research Institute (MEMRI) tend to show that Al Qaeda uses encryption tools for a long time: "Since 2007, al-Qaeda’s use of encryption technology has-been based on the platform Mujahideen Secrets qui HAS Developed to include medium for mobile, instant messaging, and Macs. "[Xiv] The encryption of communications then stopped to emails and" mujahedin secret "platform.
The year 2013 marks a turning point in the spread of encryption: Instant Messaging in February with Pidgin, SMS in September with Twofish, texts on December AES web sites. [Xvi] Edward Snowden’s revelations, which began in June 2013, are not the starting point of the "cryptodjihad" but seem to have played the role of accelerator.
The jihadists also use proprietary encryption tools, they themselves have developed, such as Amn al-Mujahid (Al-Fajr Technical Committee) or al-Asrar ghurabaa used by ISIS. It seems that every movement has wanted to develop its own tools. [Xix] On its forum, ISIS promotes the use of Tails.
This talk will speak to the issues pertaining to supply chain security as is relates to global organizations and the highly interconnected nature of suppliers and corporations. The presenter will pull from personal war stories to help illustrate the need to not just worry about the main corporate security perimeter, but to address the extended perimeter and the exposures and risks that arise from the supply chain. Such aspects of an exposed supply chain include trading partner networks, code developed by offshore development centers, and outsourced help desks.
Talking about Agile security has been going on for 10 years or so now, including best practices, guidelines, what to do, etc. I am here from the other side of the map, after trying to implement several practices - obviously some didn’t work - and I wanted to share my experience of the areas where most Agile practices will hold back security.
This ‘pits’ are common across organizations and enterprises, so there is advice to go around for everyone.
Software products requiring high privileges, usually administrative rights, in order to perform their functions are an interesting target for attackers, because vulnerabilities in such software products may be leveraged for privilege escalation attacks.
In this talk, it will be shown how vulnerabilities in popular, widely-used client management software products can be exploited for escalating privileges.
Application whitelisting is a concept which can be used to further harden critical systems such as server systems in SCADA environments or client systems with high security requirements like administrative workstations. It works by whitelisting all installed software on a system and after that prevent the execution of not whitelisted software. This should prevent the execution of malware and therefore protect against advanced persistent threat (APT) attacks. In this talk we discuss the general security of such a concept and what holes are still open for attackers. After that we focus on a product which can be used for application whitelisting to see the bypasses in practice. This will include different techniques to bypass the application whitelisting to achieve code execution, bypass read- and write-protections as well as a discussion on user account control (UAC) bypasses on such protected systems. Moreover the security of the memory corruption protections will be discussed. At the end some product related design flaws and vulnerabilities will be presented.
ZigBee is one of the most widespread communication standards used in the Internet of Things and especially in the area of smart homes. If you have for example a smart light bulb at home, the chance is very high that you are actually using ZigBee by yourself. Popular lighting applications such as Philips Hue or Osram Lightify and also popular smart home systems such as SmartThings or Googles OnHub are based on ZigBee. New IoT devices have often very limited processing and energy resources. Therefore they are not capable of implementing well-known communication standards like Wifi. ZigBee is an open, public available alternative that enables wireless communication for such limited devices.
ZigBee provides also security services for key establishment, key transport, frame protection and device management that are based on established cryptographic algorithms. So a ZigBee home automation network with applied security is secure and the smart home communication is Protected?
No, definitely not. Due to “requirements” on interoperability and compatibility as well as the application of ancient security concepts it is possible to compromise ZigBee networks and take over control of all included devices. For example it is easily possible for an external to get control over every smart light bulb that supports the ZigBee Light Link profile. Also the initial key transport is done in an unsecured way. It is even required by the standard to support this weak key transport. On top of that another vulnerability allows third parties to request secret key material without any authentication and therefore takeover the whole network as well as all connected ZigBee devices. Together with shortfalls and limitations in the security caused by the manufacturers itself the risk to this last tier communication standard can be considered as highly critical. This talk will provide an overview about the actual applied security measures in ZigBee, highlight the included weaknesses and show also practical exploitations of actual product vulnerabilities.
Therefore new features in the ZigBee security testing tool SecBee will be demonstrated and made public available.
AWS provides a vast amount of services — some are made explicitly for security purposes others only touch the subject.
This is a hands-on talk about the most important components for a security minded deployment; starting off on the network layer (VPC, security groups, and network ACLs), covering specific services (like instances, caches, and databases), and concluding how to monitor and log all the things. In addition we take a look at data encryption for storage and databases as well as the key managment options.
Incident Handling Automation with intelmq - Sebastian Wagner and Aaron Kaplan
Spam sending devices, botnet drones, scanners, c&c servers, compromised servers, DDoS infrastructures, phishing websites - the Internet and it’s doubtful places and participants. Most of these are known: They are listed on blacklists or domain generation archives, detected by honeypots. National Computer Emergency Response Teams such as cert.at or the german BSI collect all kind of this open source data, enrich, deduplicate and group it, and finally distribute the incidents to the responsible system administrators, provider’s abuse contacts and autonomous systems.
Together with other CERTs, CERT.at is developing an open source software to automate this process, while keeping the architecture simple, well scaling and reducing complexity: IntelMQ.
IntelMQ is a solution for CERTs for collecting and processing various security feeds, pastebins, tweets and log files using a message queueing protocol. It’s a community driven initiative called IHAP (Incident Handling Automation Project) which was conceptually designed by European CERTs during several InfoSec events. Its main goal is to give to incident responders an easy way to collect & process threat intelligence thus improving the incident handling processes of CERTs.
But IntelMQ is not only useful for national CERTs! You can use it as a general data flow / data processing tool for handling log files or blocklist infos and creating actions on it (such as blocking IP addresses on IPS systems).
In the talk I will talk about the problems of PDFs in the context of web browsers and websites:
Lockpicking - openlocks.at Team
Learn and practice how to circumvent physical security precautions, especially pin tumbler locks. There will be locks for beginners with just one or two pins and some more challenging ones for experienced lockpickers. You can drop by anytime, grab some tools and pick away. We will explain the basics to everybody and give you feedback on your technique. You can also try an electropick, a pickgun or other special tools if your fingers get sore.)
Logfile Analysis is the staff of life of every sysadmin or developer. You have to read and understand logfiles in order to troubleshoot the problem.
This is especially critical when it comes to security incidents, e.g intrusions. OSSEC is pretty good at that.
I’d like to show that by combining OSSEC with the very popular ELK stack (Elasticsearch, Logstash, Kibana) you can get a pretty decent open-source SIEM. It might not be as professional as the commercial ones, but it does a pretty good job. With a bit of customization you can build Compliance dashboards (e.g PCI DSS, CIS).
This would be more in a show & tell fashion…
I would also like to show the rootkit detection module in OSSEC. Currently it checks locally for rootkits, checks for suspicious files. It also tries to scan for CIS hardening procedures, unfortunately this is very incomplete yet, and there are considerations to replace it with OpenSCAP to reach its full potential.
With this presentation I want to raise awareness of OSSEC and highlight its potential as a decent host intrusion detection system. My hope is that afterwards some people might participate in the development of OSSEC (after all it’s on github)
Writing your first windows exploit in less than one hour - Workshop - Klaus Gebeshuber
Starting with some basics about stack layout, function calling, buffer overflows, overwriting return addresses and finding such vulnerabilities in software products we will explore some hands on examples - doing a straight forward exploit development with disabled mitigation mechanisms of modern operating systems. Trigger a buffer overflow using fuzzing techniques, working with an attached debugger, analyze registers after a crash, find the right offset to overwrite registers, create a shell code, find a way to jump to the shell code, encode the shell code and execute it. Now, you will have your first working windows exploit in your pocket.
At the end of the workshop, there is room for discussions. We will talk about exploit mitigation techniques like ASLR, DEP, SafeSEH, SEHOP, Stack canaries and some bypassing methods using advanced exploitation techniques.
Please pay attention to the requirement for this workshop:
<ul><li>Bring your own computer with</li><li>KALI Linux 1 od. 2 - as VM oder native</li><li>VMWare Image with Win-XP SP3</li></ul>
Steganography in File-system Metadata - Sebastian Neuner
I present you a new technique to hide data in file system metadata, in particular using timestamp information. For this approach usable, are all file systems with nano-second granularity, meaning major file systems like NTFS and ext4. Considering the PoC, the amount of hidable data is about 1 megabyte on a typical drive with 160.000 files (initial Windows 8 installation). This embedded data is protected by error correcting codes and strong encryption. Due to the required indistinguishability of encrypted data to random data, the embedded data is also indistinguishable for an adversary.
Elliptic Curve Cryptography (ECC) is based on cyclic groups, where group elements are represented as points in a finite plane. All ECC cryptosystems implicitly assume that only valid group elements will be processed by the different cryptographic algorithms. It is well-known that a check for group membership of given points in the plane should be performed before processing.
However, in several widely used cryptographic libraries we analyzed, this check was missing, in particular in the popular ECC implementations of Oracle and Bouncy Castle. We analyze the effect of this missing check on Oracle’s default Java TLS implementation (JSSE with a SunEC provider) and TLS servers using the Bouncy Castle library. It turns out that the effect on the security of TLS-ECDH is devastating. We describe an attack that allows to extract the long-term private key from a TLS server that uses such a vulnerable library. This allows an attacker to impersonate the legitimate server to any communication partner, after performing the attack only once.
Last year I started the Fuzzing Project as a coordinated effort to fuzz free software applications. Although fuzzing is a very old and well known technology, it turned out that it is trivial to find potential security vulnerabilities with fuzzing in many widely used free software packages.
Over the past year I reported hundreds of bugs found via fuzzing, some of them in important packages like GnuPG, OpenSSH and OpenSSL. In May the Linux Foundation’s Core Infrastructure Initiative decided to fund my work.
While fuzzing is usually used to find typical memory corruption bugs like buffer overflows and use after free errors surprisingly it is also able to find bugs of a very different kind, for example crashes in UI interactions or calculation bugs in bignum math libraries.
Out software base could be a lot safer if we’d just use the tools that are readily available today. The fuzzing tool american fuzzy lop (afl) has redefined the state of the art in fuzzing and Address Sanitizer is a mighty compiler feature that is able to find many hidden memory corruption issues.
Lately I’ve also investigated the possibility to use Address Sanitizer in production code by compiling a full Linux system with it.
La Quadrature Du Cercle – The APTs That Weren’t - Marion Marschalek
For more than two decades classical threat detection has painted the world black and white. Offense and defense were fighting each other like on the battlefields of Tattooine, not realizing how compartments started to shift years ago. Lines between enemies and defenders have blurred, the good guys now write exploits, malware authors from yesterday turned into well-paid contractors serving legitimate companies. Security vendors on the other hand have developed a habit of ‚threat watching‘ over the old-school ‚threat detection‘, propelling marketing campaigns and fueling political debate.
Today’s internet is no-mans-land where use of malicious software becomes a question of moral instead of a legal one. This talk focusses on the other side of APT, where nation states and law enforcement agencies mix in with the average criminal. What’s the risk coming from exotic nation state malware? Which countries are active on this sector, which ones rather just want to be?
IT Security is often considered to be a technical problem. However, IT Security is about decisions made by humans and should therefore be researched with psychological methods. Technical/Engineering methods are not able to solve security problems. In this talk I will introduce the Institute’s research programme about the Psychology of Security. We are going to research the psychological basics of IT security, including:<ul><li>How do people experience IT security?</li><li>How are they motivated?</li><li>How do they learn?</li><li>Why do people tend to make the same mistakes again and again (Buffer Overflow, anyone?)?</li><li>What can we do to prevent security incidents?</li><li>Which curricula should be taught about IT security?</li></ul>
In this talk, we give an overview of "Combinatorial Security Testing (CST)", a recently established branch of Combinatorial Testing (CT). We show how structure in the test case generation process of software testing can be leveraged to reveal security vulnerabilities. We present two applications of CST: XSS and operating system kernel testing. XSS is among the top ten most critical web application security risks according to OWASP. Applying CST can not only significantly increase the quality of software, but can provide mathematical guarantees of trustworthiness that in particular certain security properties are respected by an implementation. We conclude with some open problems and future directions for research.
Transport Layer Security (TLS) is the most important standard to secure communication cryptographically on the Internet. The TLS protocol is the result of an ad-hoc design that evolved over the last two decades – technically an historically grown mess. The TLS specification includes a vast baggage of different handshake and encryption options, some of which have been deliberately inserted during the crypto wars of the 90ies as government backdoors, which led to the discovery of the so-called logjam attack as late as 2015; other cryptographically weak options have been added to the protocol for reasons unknown to mere mortals. This talk will focus on KCI-vulnerable cipher suites , which we have recently demonstrated at an academic conference (USENIX WOOT’15: Prying Open Pandora’s Box ) to be exploitable in real-world scenarios. Although probably nobody on the Internet intentionally uses KCI-vulnerable cipher suites, we found TLS client libraries that nevertheless implemented these lesser known corners of the TLS specification. In addition to explaining the technical details of the attacks, we will live-demo for the first time in front of a security/hacker crowd a successful MitM attack against a well-known target site by forcing an unpatched client to use KCI-vulnerable cipher suites. In addition, we will discuss new, hitherto not publicly discussed attack vectors to carry out a successful KCI-based attack. We will conclude the talk with hints for further promising research directions.
A walk through the history of modern cryptography, it’s spread and subsequent scrambling by governments to control the technology. The main focus will be the renewed efforts by governments to control crypto, circa 2012 onwards, with a quick background in the first crypto wars circa 1990s. I’ll finish with a more positive countermeasures section.
Why most probably the alien mother ship will not be infected by a computer virus? And why can’t the CSI stuff trace the IP of a suspect with a single touch of button? In this talk, we take a look on how Hollywood and TV series portrait computer security and present many ridiculous and a few accurate examples.
Our closing talk