AppSec Europe 2014

Adversaries today are technically advanced, structured around an underground governed by market forces, and using paradigm shifts in technology to compromise more victims. We examine techniques for identifying, anonymizing, and sharing threat intelligence and discuss use cases ranging from DDOS to malware where this approach can speed response times and prevent breaches.

We all know JS crypto is flawed, right? Over the years, security community has pointed out its multiple fundamental problems. Several arguments were made and "JavaScript cryptography is bound to fail" became a mantra. Of course, despite all this JS crypto WAS used all over the place. Theory met practice - it was about time to dig into this!

In recent months, we tested various high-profile, in the wild crypto libraries, applications and systems. We saw code from home-grown cryptography to full-blown TLS or OpenPGP implementations. Hilarious bugs were spotted, protections were bypassed and systems were pwned. But was it really that different from what we all had already seen in OpenSSL, BouncyCastle or GnuPGP? Can we actually fix all those bugs? Does it mean that Javascript cryptography can be, pardon us saying, secure like any other?

Come and listen. During the talk vulns will be shown, authorities - questioned, myths - debunked, and browsers cursed upon. You'll see the full picture - from XSS, to man-in-the-middle, to PRNGs and timing side-channels, even snippets in C. No stone will be left unturned, nothing will be taken for granted. You'll be left with an updated, solid and heavily opinionated view of JavaScript cryptography.

What is this all about?

The OWASP Security Shepherd project has been designed and implemented with the aim of fostering and improving security awareness among a varied skill­set demographic.This project enables users to learn or to improve upon existing manual penetration testing skills. This is accomplished through lesson and challenge techniques. A lesson provides a user with a lot of help in completing that module, where a challenge puts what the user learned in the lesson to use.

Security Shepherd covers the OWASP Top Ten web app risks and has recently been injected with totally new content to cover the OWASP Top Ten Mobile risks as well. Using these risks as a challenge test bed, common security vulnerabilities can be explored and their impact on a system understood. Many of these levels include insufficient mitigations and protections to these risks, such as blacklist filters, atrocious encoding schemes, barbaric security mechanisms and poor security configuration. The modules have been crafted to provide not only a challenge for a security novice, but security professionals as well.

Over the last year the OWASP Security Shepherd has proven itself to be a resilient platform in which CTF (Capture the Flag) events can be deployed upon. Examples include

1. 
   The OWASP Global CTF 2013
   
   


2. 
   IRISScon 2013 Cyber Security Challenge
   
   


3. 
   The OWASP EU Tour 2013 Online CTF
   
   


4. 
   Source Conference CTF
   
   


5. 
   The OWASP LATAM 2013 Tour Online CTF
   
   


6. 
   The OWASP Ireland AppSec 2012 CTF
   
   

One of the biggest concerns that organisers of CTF competitions have is that their system or scoreboard may be compromised. There are few open source projects that offer a secure CTF platform to utilise. With the Shepherd platform been subject to the playful prods and less playful assaults from five continents, it is a candidate to fill this gap. The OWASP Security Shepherd is in the process of been forked to provide the OWASP Shepherd CTF Platform. 

Teachers of Application Security in higher education institutions and universities are presented with some unique challenges, especially when compared to other scientific or even computer science fields. This is mainly because students have to learn how to design, implement and protect applications against both known and unknown attacks. Moreover, the so far established stereotypes present the potential intruders as being ingenious and able to penetrate almost every system.

The OWASP Hackademic Challenges Project introduces the "attacker's perspective" in higher education by implementing realistic scenarios with known vulnerabilities in a safe, controllable environment. Students can attempt to discover and exploit these vulnerabilities in order to learn important concepts of information security through the attacker's perspective.

Its main difference from other projects that implement vulnerable applications for educational purposes, is that it is has been created mainly for use in a classroom environment, while most other solutions take a more self-learning approach. The OWASP Hackademic Challenges are not just another set of vulnerable applications but a complete teaching environment. In this manner, students can be organized in classes with different set of challenges per class. A sophisticated grading system allows the assessment of students according to their effort and performance and not just the ability to solve the challenge, while several forms of cheating can also be detected.

The OWASP Hackademic Challenges are currently being used by more than a dozen universities around the world and are also part of the "Hacking Lab" and "OWASP University Challenge". In addition, we have received contributions to the project by several researchers, including the New Jersey Institute of Technology.

The OWASP Hackademic Challenges simulate real-world scenarios that application security consultants and penetration testers encounter during their day-to-day engagements, combined with the academic requirements of a related module. These exercises can be used to complement the respective theoretical lectures. Statistical analysis of the feedback we received from students through questionnaires, shows that the students embraced this approach and have benefited significantly from going through these exercises. In practice, the OWASP Hackademic Challenges help students become more enthusiastic about application security by gaining a realistic, hands-on experience on some real-world vulnerabilities.

In this presentation we will give an overview of the Hackademic Challenges and analyze its scientific background. In addition, we will present new features introduced to the interface that was developed during the Google Summer of Code 2013 which include a plugin API. Moreover, as the project is still under development, we expect a bunch of new features to be ready by the conference dates.

We will introduce the new concept of training modules, a significant addition whose aim is to integrate entire teaching modules. A training module refers to a bundle of reading material and challenges with specific scoring rules. This allows the users/professors to manage complete logical entities and allows for better modularity of the courses. Also, in our experience there is a significant number of students who once they finish a security course, they wish to write challenges and improve the course in general. This concept will allow them, and anyone wishing to contribute course material, to provide entire logical modules in a bundle. Also, this method allows for easier integration of other useful features which are being developed, such as gamification.

Our goal is to create an educational ecosystem around Hackademic that includes teachers, students and professionals who contribute and consume teaching material and realistic challenges in an open way.

Finally, we will introduce an open id integration module. This showcases a good security practice and allows the users to login with many popular open-id providers, simplifying the registration process.

A demo of the new Hackademic portal and challenges will also be delivered, emphasizing on how it can be used in a real classroom and giving the chance to attendees to get their hands on it. 

Many, many conferences nowadays come with "HTML5 is insecure" or "Hacking with HTML5" talks. This has lead to a general perception that HTML5 itself (whatever the term actually stands for) is insecure and, thus, should be avoided for security reasons. This is highly unfortunate, as the current generation of new Web APIs expose a level of security sophistication, which is unparalleled in the Web's history. In fact, new browser features such as CORS or PostMessage allow, for the first time, to securely realize usecases which, up to now, required the programmers to resort to insecure programming practices. 

In this talk, we will systematically explore security relevant HTML5 APIs. To do so, we discuss their respective security architecture and, more importantly, show how they compare to currently established techniques which were designed to realize similar use cases. 

Plainly speaking you can consider this talk as a "information security deathmatch - HTML5 vs. its alternative" (spoiler: HTML5 wins). 

More specifically, the talk will cover: 

# Client-side cross-domain communication: 

- CORS (HTML5) vs. JSONP and/or crossdomain.xml 

# Client-side persistence 

- LocalStorage (HTML5) vs. Cookie-hacks 

# In-browser communication 

- PostMessage (HTML5) vs. 
-- hash-identifier passing and/or 
-- window.name setting and/or 
-- domain relaxation 

# ClickJacking protection 

- X-Frames-Options (HTML5) vs. JavaScript framebusters 

# Bonus track: The browser's new security capabilities 

A quick overview of new browser features that can be used to secure Web sites: 

- Content Security Policies 
- Sandboxed iFrames 
- Strict-transport Security 

The session's content is based on the experiences and lessons learned of a international academic research project on modern Web security (WebSand, http://websand.eu) of which the speaker is the technical lead. All given details will be backed with empirical data (when applicable). Furthermore, all discussed technologies can be accompanied with proof-of-concept code or practical demonstrations (if time permits). 

Among application security stakeholders, Chief Information Security Officers (CISOs),are responsible for application security from governance, compliance and risk perspectives. The recently released OWASP CISO Survey provides tactical intelligence about security risks and best practices to help CISOs manage application security programs according to their own roles, responsibilities, perspectives and needs.

The Payment Card Industry Data Security Standard (PCI DSS) applies to whether cardholder data is stored, processed or transmitted. This presentation will examine the best practices in development of bespoke or custom written applications to be used within the cardholder data environment of the Payment Card Industry Data Security Standard (PCI DSS) to ensure the applications meet the compliance requirements of the standard. 

The objective of the talk is to inform those who are developing applications of the PCI DSS requirements, review the testing procedures that an auditor would use to examine compliance with the requirements and highlight the evidence the auditor will be expecting to collect to prove the requirements are being met continually. The purpose is to help them develop applications securely to the requirements. 

The presentation starts with an explanation of the applicability of the PCI DSS and how organisations may not be aware that they need to comply with the requirements, as they may not be directly involved with payment card transactions. Often, payment card details can be captured on expense tracking systems, corporate card management and other systems. Anywhere the PAN is captured, stored, processed or transmitted, even when not directly involved in a payment transaction, the PCI DSS still applies. For web applications such as shopping carts, although the checkout may redirect to a 3rd party, the application performing the redirect needs to be secure to prevent the redirection mechanism being manipulated to point to a malicious 3rd party site. 

Version 3 of the PCI DSS standard mandates a number of key best practices to ensure applications used provide the minimal level of protection of cardholder data during processing, storing and transmission of cardholder data. 

The key practices that will be covered are:- 
• Secure software development lifecycle practices that ensure the inclusion of security during the requirements definition, design, analysis, and testing phases of software development. 
• Requiring developers to understand how cardholder data is handled in memory, and how modern malware will scrape memory to retrieve sensitive data. 
• The use of separate development, testing and production environments; including separation of duties for developers, testers and production administrators. 
• The need to remove test account credentials and test data from application before it is released to the production environment. 
• Prohibition of the use of ‘live’ data for testing or development purposes. 
• The use of change control mechanisms to ensure all changes to system components are reviewed and authorised. 
• Software developers are trained in secure coding techniques and develop applications on secure coding guidelines. 
• The testing of applications to ensure they do not suffer from known vulnerabilities. 
• Public facing web applications are protected against known attacks. 

Each of these key practices will be examined from the point of view of a PCI Qualified Security Assessor. The author, who is a QSA, will look at how industry standards, such as those developed by OWASP, can be used by developers, testers and managers as part of the process of implementing a secure development lifecycle and used as evidence in meeting the PCI DSS requirements. 

The authors view on the key practices will be given, including interpretation of the requirements and how a QSA could expect to see them implemented to meet the testing requirements of the PCI DSS. 

The result should be that developers will understand when the PCI DSS could apply to applications they are developing and the best practices they will need to follow to ensure those application meet the requirements of the PCI DSS. This will enable those merchants and service providers using the applications in their operations to achieve compliance. 

Today mobile devices and their application marketplaces drive the entire economy of the mobile landscape. For instance, Android platforms alone have produced staggering revenues exceeding 9 billion USD, which unfortunately attracts cybercriminals with malware now hitting the Android markets at an alarmingly rising pace.

To better understand this slew of threats, in this talk I present CopperDroid, an automatic VMI-based dynamic analysis system to reconstruct the behavior of Android malware.  Based on the key observation that all interesting behaviors are eventually expressed through system calls, CopperDroid presents a novel unified analysis able to capture both low-level OS-specific and high-level Android-specific behaviors. 

Extensive evaluation on more than 2,900 Android malware samples, show that CopperDroid faithfully describes OS- and Android-specific behaviors and, through the use of a simple yet effective app stimulation technique, successfully triggers and discloses additional behaviors on more than 60% (on average) of the analyzed malware samples, qualitatively improving code coverage of dynamic-based analyses.

The history of anonymous communications on the Internet dates back to the early 80's but since then there have been dramatic changes in how anonymous communication systems have been built and how they have been used. In this talk I will describe some of these key changes, and what has motivated them. These include the web taking over from email as the major means of communications, and users of anonymous communication systems prioritising censorship-resistance over privacy. The growing popularity of anonymous communication systems has also led to commercial and political realities effecting how projects are run and software is designed. In particular, I will discuss how the Tor software has changed, and the Tor project evolved in this environment. I will conclude by summarising what might be the future for anonymous communication systems and how they may have to adapt themselves to changing circumstances.

Managing all application security activities as part of development and deployment of applications can be an overwhelming challenge. OWASP OpenSAMM gives you a structural and measurable blueprint to integrate OWASP best practices in your software life cycle. This OWASP framework allows you to formulate and implement a strategy for software security that is tailored to the risk profile of your organisation. 

During this talk Bart and Sebastien will get you up to speed on the OpenSAMM framework and share their important challenges they faced in implementing the framework within various organisations. Important topics that will be covered during this presentation are: 

• What is the optimal OpenSAMM maturity level for your organisation? 


• At which level to implement OpenSAMM in the organisation: at company, business unit or development team level? 


• How to integrate OpenSAMM activities in agile development? 


• How to apply OpenSAMM on suppliers or outsourced development? 


• What metrics does OpenSAMM provide to manage your secure development life cycle? 

Practical lessons learned and use cases from the trenches that make OWASP OpenSAMM a valuable methodology and which you should apply for your secure development life cycle! 

Prior to the conference we organise a full day training on OpenSAMM, make sure to reserve your seat at this free OWASP training. After the conference the OpenSAMM project team comes together for their first OpenSAMM summit in Cambridge. If you want to contribute to this flagship project, stay and join us at the summit. More details on www.opensamm.org. 

CSP is a valuable defence against XSS and other attacks on web applications. This talk provides an introduction to the technology, why it's needed, how it works and also provides some hints on overcoming a few of the challenges presented by using CSP in the real world.

 

Threat Modeling is a software design analysis method that looks for security weaknesses by juxtaposing software design views against a set of attackers. 

Software engineers and security practitioners at Intuit have been practicing Threat Modeling in various ways for years. Intuit has used a Threat Model methodology based on STRIDE. The approach had many advantages, but also some drawbacks. Some of the drawbacks included amount of time required to translate the information from development (generating the Data Flow Diagrams) and difficulty in modeling different threat agents. 

Intuit and Cigital unified their two Threat Modeling methodologies to produce an approach that satisfies various stakeholders at Intuit. The result was what is called Unified Threat Modeling, an approach that consists of identifying assets and attacker profiles, and documenting and suggesting a list of controls. It works for software architecture and system deployments (using System Threat Modeling approach) as well as for interaction between different software and system components (via Protocol Threat Modeling approach). 

Despite many publications and presentations detailing threat modeling and, more generally - Architectural Risk Analysis (ARA) techniques, and widely accepted notion that it is so much cheaper to deal with security issues proactively and upfront, rather than reactively in already released applications, many software development teams still have not embraced ARA as a mandatory part of their SDLC. Why is it so, if the benefits are so obvious? Because establishing ARA as a regularly practiced activity is a very complicated process, and existing industry materials and methodologies do not help development teams make this transition any smoother. This presentation, based on first-hand experiences and observations from introducing ARA into SDLC, will describe the many obstacles to broad adoption of ARA in a software development company as an integral element of regular product development cycle.

The reasons for the existing situation are plenty, ranging from mindset of software engineers, to lack of security-related culture, and to shortage of sufficiently skilled security professionals. Instead of trying to tackle these challenges, many companies aim to placate customers' security assurance demands by going down the easier route of "testing security in" and contract security verification out to external vendors. These problems may be attributed to inertia and general lack of understanding of how to write secure software.

Unfortunately, there are many problems with the threat modeling and ARA methodologies themselves, which complicate their adoption as proactive defense mechanisms. There are no commonly accepted methods to calculate Return on Investment (ROI) of such programs, and senior management, with very few exceptions, remain skeptical when asked to further burden already strained development teams. In the best case, they may tolerate it, but support is far from guaranteed. The concepts and skills, required for practicing those methodologies, remain foreign to regular developers, who have difficulties transitioning from functional into attacker mode of thinking. Broad developers education is challenging because the software industry as a whole has so far failed to produce any meaningful materials on attack patterns that could be relatively easily introduced into software development process. There are efforts under way, but some of them are too academic in nature, while others are way too broad and

inconsistent, making the end result unsuitable for practical applications. This stands in sharp contrast to the reactive mechanism of vulnerability alerts practice, which relies on well established and commonly used vulnerability data sources.

As a result, despite lots of talk about great importance of ARA, and quite a few years after introduction of the concept into the applied software development discipline it remains more of an art than a trade. ARA and threat modeling are still practiced by relatively small and exquisite groups of dedicated security professionals, either within Software Security Groups (SSGs) in large companies, or by highly specialized consultancies.

This presentation will look at the key ingredients necessary for establishing a successful ARA program in a software development organization, recognizing the limitations and obstacles described earlier. The process of bridging the current knowledge gap requires close cooperation of both development and security teams, so the presentation will be particularly useful for development managers and architects involved into implementation of SDLC within software development organizations, as well as application security professionals dealing with software development teams. Finally, we will also discuss specific examples of what is lacking in the currently available public materials for threat modeling/ARA and how this situation could be improved to make those materials more applicable as part of the regular software development process. 

Web sites continually raise several issues of concern that affect individual users' freedom. As part of their design, such web sites often make users run nonfree software (perhaps in Javascript) whilst others collect data about people or help both commercial and clandestine entities to do so. Some websites may help do the user's own computing and thus deny users control over it. Dr Richard Stallman will speak about these problems and how to avoid them.

HTML5 has been on the way for a couple of years now. There have been many discussions about its security implications and how they should be handled; however, these discussions usually stop at showing the most hyped and scariest vulnerabilities and their countermeasures. This presentation will continue the discussion on another level. To create state-of-the-art web applications with HTML5, all of its features should be analysed to see the risks they introduce and how they should be used properly. 

This presentation will analyse the Cross-Origin Resource Sharing (CORS). This HTML5 feature allows websites to load resources from other domains, even from restricted environments, using the authentication tokens saved by the browser. This has interesting effects on various actors of the Internet. It affects the clients and the servers alike bringing a whole new trust relationships in the game. It also breaks with the relevant parts of the same-origin policy, one of the most important security features of web browsers and all of these happened without most people noticing. 

The first part of my analysis will introduce the Cross-Origin Resource Sharing, how it works, how JSON-P, it's predecessor, was used and why CORS is interesting from a security perspective. The functional introduction will be followed with a threat analyses to show how CORS affects the traditional usage of XmlHttpRequests (XHR). Because it introduces a change in the way how websites communicate with each other it has an effect on pre-CORS websites as well. Most importantly it introduces a new way to attack web applications and overturns well known attacks such as Cross-Site Request Forgery and Cross-Site Tracing and gives them whole new possibilities. Examples for these will be presented in live demos. 

The presentation will be concluded with outlining the methods to mitigate the security risks of Cross-Origin Resource Sharing. The methods will include ways to prepare a site to handle CORS properly and to build new web applications enjoying the new features of CORS without risking the data of our users.

In the modern Web environment, far from heeding Ken Thompson's admonition that "you can't trust code that you did not totally create yourself," we're required to trust a whole host of things we didn't create ourselves, including code, devices, infrastructure, and institutions. Sometimes, quite visibly of late, we've seen that trust betrayed by failures in components we shouldn't have needed to trust so broadly in the first place. This talk will examine gaps in our current models of trust and security scope, and consider how, short of writing our own compiler-compilers and everything on top, we can create a more trustworthy Web.