Defcon 26 -- A Software Engineer's Perspective

This year marks my fourth Defcon, and I thought it was time to reflect on what keeps me coming back year after year, and why I think more software developers, not just info-sec specialists, should brave the Vegas heat and check out this amazing conference!

1983: The View from Dystopia's Edge

This was the theme for Defcon 26. Going to Defcon is like looking under the crawl space when you know it's been too long. There may be some cracks in the foundation!

Today's technology landscape is changing at a pace that leaves most of us breathless. With each change comes new challenges to the security of individuals, organizations and nation states.

In a short amount of time, often without realizing it, people have bought into a new business model, paying for services with their personal data. Many of these services have become deeply entrenched in our lives. The data is bought, sold and often stolen by special interest groups around the world. This data can be weaponized against the individual for the theft of money or identities. It can be used for defamation in smear campaigns. It can can also be leveraged against organizations, improving phishing and social engineering attacks. And as seen in elections around the world, it can drive the targeting and enhancement propaganda.

Behind the curtains of these services, infrastructure has moved to the cloud. It makes provisioning hardware something so simple a software engineer can do it ;-), but if the wrong credential is compromised a simple script can spin up thousands of servers for a rogue bitcoin mining operation that leaves your organization with the bill. As infrastructure gets easier to provision we naturally make more of it! Many large organizations already struggle with their cloud assets as evidenced by the bitbucket leaks that regularly make headlines. This challenge is even more daunting for resource strapped startups and non-profits operating in this space.

Wow! The edge of dystopia indeed, and I haven't even gotten to the Intel Management Engine, speculative execution attacks, government surveillance, or DIY CRISPER kits!

Seriously check out this talk if you want to be scared :-)

What I Love About Defcon

Often such issues heavy issues are met with one of two responses:

1. Denial of reality: Fake news man
2. Abdication of responsibility: There's nothing I can do about, it's all rigged

What I love about Defcon is that whether discussing trans-humanism or obfuscation of malicious binaries to fool anti-virus software, no one looks away and no one shrugs off their responsibility. It's a community seriously searching for answers in 1983. If there's a hope to avoid 1984 it's here in the spirit of this conference. If 1984 does come, it's these people who will form the underground protecting what's left of our institutions and knowledge. The discussions at defcon, I think surprisingly to some outsiders, do not just revolve around technology but are often deeply rooted in the ethics of what we are building as technologists. Ethics now has it's own defcon village!

As a person who often lets myself get mired by the dystopian muck out there, I find defcon refreshing! It's time to get to work!

Takes Homes for a Software Engineer

One thing that always disappoints me about Defcon is that so few developers attend. Most of the people I talk to are security researchers, penetration testers, or system administrators. This is a shame and serious advantage for attackers!

Brian Fox, the CTO of Sonatype, once said, Open Source Developers And Infrastructure Are The New Front Line Of Security. I would take this further. It does not matter if you develop open or closed source! If you are developing software that will be deployed on production boxes or in use on developer machines, congratulations you've been drafted to the front! There are four important things I like to think about as a developer that I was not as aware of before I began attending Defcon:

1. Personal security
2. Lateral movement (secure all the things)!
3. Dependency management and policy enforcement
4. So many cool red team tools!

Personal Security

This should go without saying, but too often I still encounter people who do not think they are a target. Everyone is a target for cybercrime but developers even more so. A developers box is a treasure trove of forgotten SSH keys, stored passwords to administrative interfaces and intellectual property. This threat vector only increases as more and more people work remotely where their machines share networks with friends, loved ones and that forgotten Raspberry Pi project still chugging away in a corner (not that I have 5 of those). We all have a responsibility to secure our personal machines and networks.

Lateral Movement

This segues well into the next point. A common theme in many attacks discussed at Defcon is lateral movement. A successful hack usually begins at the weakest link. Sometimes it's a legacy web application with bad input validation or vulnerable dependency. Every large organization has at least one poorly maintained portal sitting around that's too expensive to maintain and even more expensive to replace. Another weak link might be a sales rep that downloads the wrong PDF from an e-mail, allowing malicious code to execute behind a firewall. Whatever the entry point, the next step is lateral movement. Perhaps the crufty web portal really doesn't have any juicy data, but the box it's on can call an internal API on another machine in the network. If the API is supposed to live behind a firewall does it validate input or were corners cut? The island hopping continues, aided by a host of automated tools and scripts probing the corporate network.

As developers we can stop or greatly reduce the spread of such attacks by writing our services with the mantra "trust but verify" in mind. Https is cheap and easy to setup these days. Even if a service is behind the corporate firewall it should still have SSL. This allows the browser to verify the authenticity of responses and stops packet snooping by that malicious script running on the sales rep's windows box.

As more and more web applications leverage micro-service oriented architecture attention should be paid to how these services establish trust. Do they communicate over the network? Is their communication
encrypted, and do they exchange tokens? These services do need to trust each other but they must also verify!

Dependency Management and Policy Enforcement

As development becomes ever higher level, making use of massive frameworks and large runtime dependencies, a long tail of third party code grows behind the applications. This trend is not likely to stop because it makes too much business sense; so, we must learn to work in this space. Thankfully there are already quite a few good tools to help.

Despite some the recent headlines around compromises in
npm and brew dependency management systems are a good thing. They allow developers first and foremost to know what their dependencies are. More important they make it much simpler to bump versions as new vulnerabilities are discovered in packages while at the same time limiting unintentional version changes. I have no nostalgia for the dark days of copy pasting DLLs or JavaScript libraries into projects, trying to remember that they are there.

There is a growing landscape of tools both closed and open to enable dependency auditing. Auditjs is a tool for node projects that runs on the command line. DepShield is available as a Github application to check the dependencies of Java projects. Github itself is now weighing into this space with their own solution.

Developing healthy policies around the type of dependencies allowed into a build is an important part of secure software development. Products like IQ Server can sit between a build process and central repositories enforcing policies such as the exclusion of packages that are no longer actively maintained or contain critical vulnerabilities.

Finally there is good old fashioned testing and automated deployment. A large part of security is response time. When a new vulnerability is discovered in a dependency you will likely need to upgrade the package, the quicker the better. This means discovering any regressions introduced by a version bump, quickly fixing the regressions and shipping the change! The best way to do this is by having a culture of test driven development and battle tested reliable reproducible build processes to deliver updates.

Finally a Bit About Some Fun Tools

There are a lot of tools used by security analysts that I was not entirely aware of, but many of them are also useful for developers. At the very least they provide insight into the view of an attacker and show what's possible for a skilled adversary.

If you write any sort of web application it's worth checking out tools like OWASP Zed Attack Proxy (ZAP), Burp Suite and Metasploit. These tools can help you to map the attack surface of your applications. For example OWASP can be used to "man in the middle" a service, examining and altering data in flight. Many of these tools are scriptable and have pre-built attack patterns to check for common web application vulnerabilities.

If you take my advice and go to Defcon 27, I highly recommend stopping by the packet hacking village for a tutorial on WiresShark which is a goto tool in their annual capture the packet contest and very helpful for examining the state of your network.

If you really want to go down a rabbit hole tools like AFL (American Fuzzy Lop) help fuzz binaries and there's all sort of fun to be had with hex-editors and disassemblers. This is the code beneath the code. Beware, malware authors lurk in the shadows of poorly validated system calls seeking that ever elusive ring0. It's not long before you're sifting through memory dumps and making hex jokes (Did you know all Java Class files start with the magic word CAFEBABE). There's no going back once you've swallowed this red pill, but maybe one day you can tell me what Electron does with all that memory it uses.

Finally an Invitation to the Infosec Community

Developers aren't as terrible as some of you seem to think. Many of us are your customers and at the very least our mistakes keep you employed; so, it wouldn't hurt to stay up to date with the mess we are making. There are many great developer conferences out there. Checkout Nodevember or PyCon! This callout goes to the red and blue team alike. You know that botnet you're working on could be just a little more persistent with some unit testing and a pipeline for continuous deployment. A little software engineering may be just the thing you need to pull off the next bitcoin wallet heist ;-)