BSidesSD 2017BSidesSD

San Diego has finally joined the Security BSides (@SecurityBSides) circuit. This year, the first annual BSidesSD took place Jan 13th-14th held at National University on the northern side of San Diego. This author was one of twenty speakers accepted to talk at the inaugural event. My talk was once again centered around our WHOIS work here at OpenDNS, which we will be discussing in an upcoming blog in the future. If you have not noticed yet, I really enjoy doing the BSides* conference tour. They are usually very well organized, as this one was, and not so large in size that it makes it hard to interact with other attendees. Sadly, the waffle truck that was supposed to show up for breakfast couldn’t make it, but that was really the only let down across the entire event.

Like all conferences, there were lots of really good talks going on, but trying to cover them all would be extremely difficult, so I’ll just touch on a few of them that I thought stuck out:


David Shackleford (@daveshackleford), a Senior Instructor at SANS and founder of Voodoo Security, started off the conference delivering the keynote address. In his talk, titled Security as Code, Shackleford discussed the movement from traditional on-premise data centers over to the increasingly popular cloud based models (read: AWS, Azure, etc). With this shift, the need to stay ahead of the curve in securing applications and data, all while being able to scale at the speed of a DevOps “fail fast and often” methodology. This methodology, which aims for automated provisioning, builds and testing, no downtime, and monitoring, creates the need for a ‘DevSecOps’ team to integrate security into the cloud infrastructure. Introducing automation into the system means defining a security process that allows for proactive monitoring as code is being written and pushed out into production. This entails getting crucial feedback to look for any errors or vulnerabilities.

Continuing on, Shackleford emphasizes that this feedback should be acted on as the problem is noticed, and not after. Items such as tokens and passwords are often forgotten about in code. The last thing any company wants is for these to get exposed. Moving at the speeds we do today, having checks in place such as logging and event monitoring can help catch problems before they start. Using a problem-trigger-fix mentality, teams can let automation catch issues and push out a fix depending on X or Y events that have happened.

One of the ways that was discussed was using a template model when deploying anything into production. This way, when there is a build failure or passwords are flagged in code, it’s easy roll back to a known good previous build without any loss to production time. Going by just this one example shows how you can use both automation and the “fail fast and often” model in unison. Davids’ full talk can be found here.

The Aftermath of a Fuzz Run

CEO of Fuzz Stati0n, David Moore (@grajagandev), gave a great presentation about fuzzing. Starting with the basics, Moore walked the audience through a quick review of the more common memory corruption bugs. As Moore explains, these bugs are really invalid read/writes that are caused by a few different situations. These include off-by-one errors, invalid input, stack overflows, and use-after-free attacks, to name just a few. Moore went on to cover some of the various types of exploits used such as code-injection (attacker injects malicious code onto stack), and return-oriented programming (wherein existing code is reused instead of the attacker having to inject their own). 

Moore continued by going over how to responsibly report bugs via bug bounty programs or directly to vendors, stating clearly why the bug needs addressed. The last thing you want to do is disclose a zero-day vulnerability on a public forum by accident. Next, Moore went into some of the mitigation techniques that can be put into place such as using a Stack Canary, which places a random integer on the stack before the return address and the operating system monitors for changes or over-writes to it. Other techniques covered included the use of Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR).

The latter half of the talk went over how take the fuzzing reports and start to minimizing crash corpuses, using memory corruption tools, and determine if something is indeed exploitable. This is where the talk takes a turn for the deep dive, and is more dense than can fit in this blog. To see for yourself, the full talk is here.


SITCH: MITM Detection in GSM Network

Ash Wilson (@ashmastaflash), who operates, delved into the world of GSM Man in the Middle (MITM) attacks. Wilson explains that not only are these devices getting more and more inexpensive, but they are getting harder to detect. This talk is an extension of the work he did for a presentation at DEF CON 24 covering anomaly detection in GSM networks. Starting out with an overview of malicious devices such as hacked Femtocells, Evil BTS (Base Transceiver Station), and GPS Simulators, the presentation moved on to cover some of the various terminology and current detection methods. In a world where a lot of conversation take place over cellular phones, the threat of corporate espionage or invasion of privacy can have catastrophic effects, knowing how and where to secure your appliances in the network is crucial.

The slides from Ashs’ talk can be found on the website here and contains a lot more detail, including instructions on what you need to build your own.


As always, thanks to the organizers, sponsors, and participants for making a great event happen.

This post is categorized in: