Come compete in the DefendCon Capture The Flag (CTF) challenge!

The competition will run throughout the conference.

Prizes will be awarded for the top participants at the closing remarks session at the end of the final conference day.

This is a casual CTF, so you can hack away at your leisure throughout the conference or in the privacy of your hotel room after the first day of the conference.

Prizes will be awarded based on most challenges completed, and the challenges are not timed.

Happy Hacking Everyone!

Contest Rules & FAQ

When it comes to our individual career trajectory or the identity of our teams in a larger organization, we establish ourselves through the stories we tell. We’ll explore how narrative identities drive the essential requirement for diversity and inclusion, and why it makes security teams great.

Blockchain is the technology that powers Bitcoin. There is a lot of hype, giving the impression that it is a revolution in computing and any forward-thinking engineer should adapt their applications to run on it. It's difficult to get clear descriptions of what the technology is, and even less is written comparing its properties to what could be achieved with traditional technologies. To add to the confusion, people are using the term "blockchain" as pretty much anything that involves computers, networks, and cryptography. This talk will explain exactly how the original "blockchain" works, and why, with its enormous cost in terms of computation, bandwidth, and storage, together with its security properties, it is almost certainly not a suitable basis for most application.

In the next five years we expect to see an exponential growth in connected devices. Regulators are starting to focus on the public policy implications of the Internet of Things, and how to mitigate potential harms to consumers as a result of this ubiquitous interconnectivity. In addition to an increase in regulatory activity, participants in the production of connected devices, and aggregation and use of data culled from connectivity, are also just beginning to grapple with significant liability concerns, and how best to protect themselves from potential litigation. This session will look at policy and legal options for managing the cyber security risks associated with the development and manufacture of connected devices, the collection and analysis of data associated with the Internet of Things, and the everyday use of such devices by organizations and individuals.

Working on large and small scale incidents allows you to take a unique glimpse into a company in crisis. While falling victim to an incident is likely inevitable, companies can reduce the overall detection and response time as well as the cost associated with the incident by implementing the lessons learned from other companies. The major problem is that these details are no easily accessible. This talk will focus on recent trends in incident response, new (and old) attack techniques, and war stories. The presenter will also share suggested mitigations that can be implemented within your organization the very next day.

While there's been quite a bit of offensive research into applying traditional application security techniques like fuzzing and protocol analysis to newer technologies, the bulk of the security work needed to lock down most of the internet is considerably less esoteric. We need more techniques focusing on how to take traditional application security bugs, and how to find them using less time and resources. The way to secure the entire web looks a lot more like doing doing traditional engineering than some of the more exploitation focused research.

Traditional penetration testing of services is quite effective at finding bugs in websites. We know how to find security vulnerabilities by black boxing applications or doing source code analysis. The difficulty in relying exclusively on these methods is the cost. If you have a very large website to secure, relying exclusively on human analysis means you either gate every project around a limited security resource or you build frameworks that solve traditional bug categories.

A method i've found particularly effective has been to have good frameworks, and monitor code at diff time for errors. It's often possible to catch security bugs by monitoring the use of key parts of the framework needed to invoke security bugs by use of fairly cheap and simple techniques like string comparison for known bad patterns. Hooking into your source control system at diff time to monitor for these bad patterns lets you work with developers before the buggy code ships. Over time it also puts you in a position to train developers to use the frameworks you prefer. In this respect it's doubly powerful. Create the correct frameworks, monitor misuse or non-conformance, and train developers to use the newer better methods. This can build a positive reinforcement cycle where over time developers train each other to solve common application security problems in a safe way.

The big advantage of this method for bug finding is that you can be fairly precise about the economics of finding certain types of bugs. If it takes 10 minutes to assess source code for a cross site scripting bug, and your pattern has a 20% signal to noise ratio, you find a bug every fifty minutes of work. The individual patterns can be isolated, allowing you to improve and tune the amount of time needed to find bugs. By focusing on maximizing bugs per hour, a bug sieve method like this can provide an effective means of more cheaply finding traditional application security bugs than manual penetration testing.

An increasing number of engineering teams are migrating to using Docker containers for their applications and services. Not all security teams are prepared for such a switch though. Get up to speed on the fundamentals of open source/community container technology. This talk will focus specifically on Docker and Mesosphere. While they have lots of potential, if you don’t make optimal use of their features, your container security could be as weak as a cardboard box. Learn how you can raise the bar and make your dockerized services as secure as a steel shipping container.

Padding Oracles are a class of vulnerability that have been known since at least 1999, but yet are still not widely understood. This session provides a detailed overview of padding oracles, starting from the ground up. I argue that padding oracles are an excellent lens through which to understand the differences between confidentiality and integrity, and that too often that cryptographic protocols ignore the need for integrity, putting both the integrity and confidentiality of data at risk.

At the end of this presentation, a security engineer will be able to spot a padding oracle during a security review, and a software developer will have enough information to implement code that exhibits a padding oracles and a corresponding exploit for her own code.

Grassroots activist groups present unique and interesting security challenges. They are more than just their individual members, but far less defined than the kind of corporate network many of us are used to defending. What can we learn from them in terms of building more secure products? How can we build secure systems that protect those without a security team backing them up? And what lessons can those of us who defend more traditional networks learn from the things that do work well for such groups?