02 Mar 2017
I must be doing something right because they keep sending me to security conferences.
After going to ShmooCon last month, I got the opportunity to attend the inaugural
Security BSides Northern Virginia conference on February 25. As a 1 day event, it was pleasantly
brief and packed a lot of talks without requiring me to commit a full weekend. Also,
it took place in Herndon, which is pretty easy to get to and didn’t require a trip on
the DC metro.
Like with ShmooCon, I made a list of things that stood out to me at the conference.
The first thing I noticed when walking in is this conference attracted a lot of
big sponsors. ShmooCon actively limited the sponsorship spots and tried to showcase
smaller companies, but this one had all the big names: SANS, ISC², Symantec,
and pretty much ever contractor from the DC metro area.
I don’t have strong
feelings about this, but I was surprised since I sort of assumed that
BSides was informal and driven by community individuals (I mean, the main website is a PBworks wiki running
with an educational license, so I really didn’t expect to see Fortune 500 companies
setting up booths). I guess it’s cool that the BSides NoVA organizers were able to
get big names for the first conference.
Initial keynote was by Tennable co-founder Ron Gula (@rongula) under the title Cyber Security 2017: Trends and Start Ups which rolled
three talks into one on the topics of 1.) the cyber security market, 2.) new rules for business and 3.) how to pitch a cyber security startup to a VC.
It was oddly refreshing to have
someone talk about the intersections of startup culture and hacker culture. They
both have a lot of common ground but tend to get mired by ideology.
My favorite part of his talk was his take on the traditional 5 slide pitch deck
(they spend too much time on posturing and not enough on describing the problem
- The talk 0 to 31337 Real Quick: Lessons Learned by Reversing the Flare-On Challenge was a retrospective on last year’s FLAREOn Challenge presented by two
Endgame developers Josh Wang (@rh0gue) and Blaine Stancil (@MalwareMechanic).
These challenges were what really got me into doing reverse engineering, so I was excited to
meet someone who actually completed all of them. They didn’t reveal any of the answers,
but instead provided a rundown of all the techniques they saw.
This slide was the
central point of the talk since it provided a table with the challenges and
which reverse engineering techniques were used to solve each one:
Another interesting talk was Doomsday Preppers: Fortifying Your Red Team Infrastructure
by Steve Borosh (@424f424f) and Jeff Dimmock (@bluscreenofjeff). It focused on how a red team
can setup a successful pen test by building out simple, redundant, and redeployable
networks to keep the attack alive, even if the blue team takes active steps toward
I kind of assumed that red teams weren’t very organized and
just grasped for footholds until they got the results they needed, but this really
changed how I look at red team/blue team exercises.
The final keynote was by Georgia Weidman (@georgiaweidman)
whom I went to college with at James Madison University. She’s been much more successful than me
since then. The organizers unfortunately put her keynote in the foyer of the
building instead of an auditorium and that was a terrible idea; the sound system was
awful and it was happening alongside the happy hour so it was hard to hear anything over the
noise. My biggest complaint about the conference is that they messed this up so badly.
- But hey, there was free alcohol and food.
In addition to talks, I dropped into a few workshops. There was a Malware Analysis 101 workshop
in the schedule, but there must have been some confusion when printing the schedule
because it was actually an OWSAP workshop on identifying attack patterns from network
The other workshop I did was a Forensics 101 course that was very well put
together and instructed by Marcelle Lee (@marcelle_fsg), Brian Moran (@brianjmoran) and
Courtney Lancaster (@allth3things).
The wifi at the conference was pretty bad; probably because it wasn’t designed to hold
a ton of people all at once. I made the mistake of not downloading the workshop
materials in advance. A lot of people did the same thing. To remedy this, they began passing around a thumb drive with
all the materials. At a security conference. During a session on malware. Let this sink in.
The badges are awesome. They are an electronics reference board so they are actually
pretty useful after the con.
- I saw Bruce Potter (@gdead) wandering around. It’s
kind of cool to recognize people from other conferences.
Overall it was a fun conference. Most of the talks were aimed at a broader audience
so it was highly accessible for all levels of experience. I definitely plan on
18 Jan 2017
I went to ShmooCon!
I’ve always wanted to attend but tickets are limited and incredibly hard to get.
I was finally able to secure 2 barcodes this year so I passed one off to my
friend, Ed, and we hopped on the metro to Dupont Circle.
The easiest way to get kicked out of the conference is take photos without permission.
There’s a two strike policy on this; unfortunately that means I don’t have any
photos of the conference. There were some interesting people and displays but I was
going to respect the privacy of the attendees.
The vibe I got was that this was a gathering of good natured people and there wasn’t
going to be much cover for illegal or blatantly malicious activities (I still wasn’t going
to use the ATM in the lobby, however).
After 3 days of talks and shenanigans, I made a few retrospective notes.
- How did I get a barcode? No gimmicks. I just went to the website and hit F5 as the site went live. My Internet connection at home is reasonably good and I think this helped.
- Want to blend in? Wear a black tshirt and jeans. Want to make it easy for your friends to find you? Wear anything else.
- There were two talks that really stuck out to me. The first was Anti-Ransomware: Turning the Tables by Gal Shpantzer and G. Mark Hardy. The presenters discussed why ransomware is such a big deal now (hint: money) and
how it’s getting more sophisticated (e.g. being able to detect if VPN software is present and
waiting for a connection for better exposure). The other talk was Goodnight Moon & the House of Horrors: A look at the current IoT ecosystem and the regulations trying to control it by Whitney Merrill and Aaron Alva.
IoT is still a garbage fire from a security perspective and this talk discussed possible
regulations to try to contain it.
- I mostly attended talks. I regret not visiting some of the side rooms and participating
in the lockpick village. Next time I plan on dedicating at least half a day to
visiting these. A co-worker spent most of his time doing Hack Fortress and his
team wound up winning the championship. My TF2 skills are a little too rusty to
join a team, but I might consider doing that next year.
- The Metro sucks. If you are coming from out of town, you might not know about the delays, shutdowns, and fires. I highly recommend giving yourself extra time if you plan on using it. This is especially true if you plan on using the disability access elevators since these are notorious for being out of order.
- A VPN is highly recommended, even for the WPA secured Wifi networks. Cell service was pretty bad.
Probably because of all the devices.
- The food situation was wasn’t ideal. There was an impromptu bar set up in the
lounge area where food was being sold, but it wasn’t great. Dupont Circle has some good
restaurants within walking distance, however.
- The Friday night fire talks were fun and probably the best part of the day (also the lightest attended).
- Get a Twitter account. Set up alerts from @shmoocon. You’ll get buzzed when stuff happens. Also you can set up a list of all the speakers you saw so you can follow up with them later.
- I kept sitting behind Ed Skoudis (@edskoudis) at various talks but
I didn’t realize it was him until some of his tweets later.
Overall, it was pretty awesome. If I can get a barcode for next year, I’m definitely going back.
There are a few other hacker cons being scheduled that I might attend in the meantime, including
BSides DC and, of course, DEF CON.
Dupont Circle Station, Wikimedia Commons
15 Aug 2016
I’ve been quietly working on a new project that just recently went into a closed beta release.
Back in college, I was studying a lot of information security. I was even on my university’s cyber defense team where we competed at a regional competition to defend a computer network against a nasty group of professional penetration testers.
I’m in the lower right with those sweet sideburns.
After college, I kind of moved away from doing infosec and I began to settle into a comfortable web application development career. I still tried to keep up on the world of infosec by reading blogs and following news articles, but it’s pretty tough unless you’re actively involved in the community.
Around 2013, I found some co-workers who also wanted to play around with infosec stuff and they let me hop on their private lab to solve challenges, learn some new stuff, and just have some fun. I was hooked back in and I instantly knew I wanted to host my own lab environment to do the same thing. I also wanted to apply some of my software engineer and dev ops skills to try to automate a lot of the boring stuff so I could spend more time exploring security concepts and less time doing admin work.
So that’s why I started hacknowledge.io. It is a private network that I’m hosting and also a set of tools for administering and monitoring the network.
Here’s how it works: I have a server in my basement running VMWare ESXi and with a few really vulnerable virtual machines. All of these VMs are on a private network that can only be accessed by going through a VPN. I’ve been calling this private network the Threat Net even though, at the moment, none of the hosts are dangerous on their own.
For each vulnerable host, there are a few challenge questions. Answering these gets you points and let you move up the leaderboard. The questions are designed to help push you in the right direction of fully exploiting the machine. They start off relatively easy (e.g. Find the port that a web server is running on) and eventually ramp up (e.g. What is the root password?).
Currently there are only 3 hosts. Eventually I’m going to have 5 for the initial closed beta round. The first three are relatively easy to exploit. Spoiler alert: the first host is vulnerable to Shellshock, which is about as obvious as they come. Anyone who knows how to install and run a Nessus scan can figure it out. I’m hoping that I can eventually build out some more difficult challenges in the future, but the closed beta is mostly just a proof-of-concept.
In addition to vulnerable hosts, the threat net also has some bots running around doing housekeeping chores like reverting the VMs to a known state every half hour (so you can trash a machine and it will be back to normal so someone else can have a chance). There’s also a bot that just checks to make sure the machines are online and available.
Outside of the Threat Net is a set of hosts that provide a web interface for users to answer challenge questions.
In the process of designing and writing all of this, I learned a bunch of stuff. I have a ton of blog entries planned on how I built this thing.
23 Jan 2016
I’ve been doing professional software development for nearly eight years. That’s not an exceptionally long time, but it’s twice as long as the time I spent in college as an undergrad and it seems like a good place to stop and do some reflection.
I recently noticed at work that I’m now on the top of the heap with more junior developers working alongside of me than ever before. My input is weighed more heavily, my contributions are valued more highly, and I think I’m even getting small glimpses of this new feeling called “respect”. It’s an exciting time.
With all this new clout, I’ve compiled a short list of the ways that I’ve grown as a software developer.
I’ve learned to not be a control freak
Early in my career, I worked on really small teams on small, tight projects. I could know every detail of the baseline and know exactly how all the pieces fit together. I saw the projects as direct extensions of my worth and I found myself really nervous if I heard someone was trying to make some big changes. What if they don’t get my elegant designs and just kludge the whole thing up? What if they don’t have my same skills as me and turn the whole thing into an unmaintainable mess for me to deal with?
I had two options: I could constantly be checking the work of these outsiders and spend hours trying to “clean up” their messy less-than-perfect code. Or, I could just let go of my control freak nature and let them contribute like a professional. This has been incredibly difficult for me to do, but I’m finally getting around to it. If I tried to monitor every single code check-in and every change being made, I wouldn’t have any time to get real work done. On top of that, I’d look like a jerk who can’t play nice with others.
In the end, I really have to remind myself a few things:
- The success or failure of a project doesn’t depend solely on me.
- I was once a wide-eyed junior programmer who couldn’t wait to start contributing, no matter how little I knew of the code. I turned out okay.
- You gotta let things go sometimes. Walking away isn’t a sign of defeat or apathy.
I’m less concerned with style
Spaces versus tabs. Semicolons versus semicolon-free. Single quotes versus double quotes. So many battles rage on within software development teams. I have strong opinions of what good clean, readable code should look like, but these days, I’m much less apt to try to enforce it on others. We have a style guide at work for our code and I only like about half of the style choices, but I’m not about to spend the effort to try to change people’s minds on really petty stuff.
I have a theory on this: in college, I was used to doing work and getting a grade on it. It felt good to get validation. In the real world, I might go weeks before getting feedback from someone on my work, and even then, it might just be superficial. For a while, I really craved the kind of validation that I got from jshint and pylint and whatnot. To me, it was a way to write code and have someone tell me that it’s “good”.
I’ve discovered that even well-styled code can still be pretty lousy and I think I’ve outgrown the need for the praise.
My unit testing is way better
Unit testing is a skill that, unfortunately, doesn’t seem to be taught in college and most developers aren’t actively seeking out tutorials or books on how to write good unit tests. Most new developers write really, really awful unit tests, myself included. I could probably write a whole blog post on how you should go about learning how to write a good test suite (I probably will at some point).
In short, your unit tests need to meet some basic criteria:
- Independent, no external requirements, –that includes databases, network connections, filesystems, etc.
- Repeatable, you should get the same result each time you run the tests no matter what order you run them.
- Concise, you should be testing one thing in each test case.
One obstacle for me was learning how to mock out objects and modules for your unit tests. Most unit testing frameworks don’t present this up front and it’s incredibly difficult to write good unit tests without a good mocking framework in your toolbelt.
The Zen of Python is everywhere
The Zen of Python is a short mantra that describes the ethos of the Python community. It’s intended for Pythonistas, but honestly, it works for every language.
When combined with some of the things I’ve gained from functional programming, I’ve found that my code feels much more elegant and even fun to write.
I’m no longer afraid of exceptions
Somewhere back in college, a lot of programmers make the connection that exceptions crash your programs. Therefore, exceptions must be bad and you should do everything you can to remove them from your code.
But exceptions are a very powerful construct! In C code, you have to return positive or negative return codes and the calling function has to interpret them and react. I don’t want to go back to that.
A lot of rookie programmers will eat exceptions and this is universally considered bad form. Another anti-pattern I often see is avoiding situations where explicitly throwing an exception would be appropriate. Usually they will return a null value and let the calling function do a null check to figure that out.
If you’re a junior programmer and want to impress your seniors, learn some of the exception handling idioms of your language and find places where they help your code.
Frameworks are cool, but not a substitute for fundamentals
Frameworks are designed, in part, to reduce boilerplate code and the amount of cruft that you might otherwise write. I used to think that knowing a framework was a fast track for writing better code, e.g. Angular.js has modules and dependency injection so it’s halfway there to making you a JS ninja.
Well, not quite. It turns out, you’ll bend the framework to your bad habits. I’ve seen it so many times that I’m starting to understand the no-framework camp of developers.
For this, I think it’s just a lack of solid hands-on time with a language. I see developers mature in the language over time as they write code and find themselves maintaining it.
I’m going to set a reminder for myself to revisit this in 5 years and see what else I’ve learned. I could have a new job by then, a new favorite language, or a new database that I love. I don’t expect to stay the same, and that’s a good thing.
18 Dec 2015
I am spending some time learning Haskell. This is partly because I want to learn about functional programming, but also because Haskell has this aura of hipster programming that I kind of enjoy.
When your industry is growing at a fast pace, it’s a good idea to stay on the edge of things.
I’ve attempted to collect together a bunch of Haskell and post them here for my own benefit, but also you can join with me as we throw off the shackles of OOP and welcome our brave new world of functional development.
Intros and Motivations
Functional Programming should be your #1 priority for 2015 by Ju Gonçalves.
A very good brief introduction to what functional programming is. This article argues that functional programming is the next big thing in computing thanks to distributed architectures (better known as The Cloud). Obviously, this article was written nearly a year ago, hence the title. The collapse of OOP didn’t occur in 2015 and it probably won’t happen anytime soon. Still, this was one of the first articles I came across that motivated me to take functional programming seriously.
This quote sums up the whole article nicely:
That promised time when we’d have applications running distributed and concurrently finally has come. Unfortunately, we are not ready: our “current” (i.e., most used) model for concurrency and parallelism, even though might solve the problem, it adds a lot of complexity.
The Dao of Immutability by Eric Elliott.
A fun meditation on the simplicity of functional programming.
All Evidence Points to OOP Being Bullshit by John Barker
Another cathartic rant on object oriented programming. There seems to be a common theme here…
I advise people to hire based on whether or not a developer believes in class inheritance. Why? Because people who love it are obstinately stubborn about it. They will go to their graves clutching to it … I won’t hire them. You shouldn’t, either. I’ve seen classes wreak havoc on projects, companies, and lives.
Why Haskell Matters from the Haskell.org Wiki
Although it’s fairly dense, this is reasoning for Haskell from the people behind it.
Unless otherwise noted, all these books are freely available online.
Learn You a Haskell for Great Good! by Miran Lipovača
This is the definitive beginner’s guide to Haskell. I remember picking this book up at a Barnes and Noble and thinking what the hell is going on with this language? Years later I actually read the book and I enjoyed the nice pace and quirky illustrations.
Real World Haskell by Bryan O’Sullivan, Don Stewart, and John Goerzen
Haskell is often unfairly categorized as an “academic” language that should remain confined within the realm of computer science theory. This book is both a tutorial and counter-argument to prove Haskell can be used in software development for serious development.
The Structure and Interpretation of Computer Programs by Harold Abelson and Gerald Jay Sussman with Julie Sussman
To be honest, I haven’t read this text. Also, it’s not actually about Haskell, but rather the overall concept of programming language design. It also makes use of Lisp instead of Haskell. I’m only including it here because it’s a monumental work that is often recommended when learning about functional programming.
Make Haste: Fast Track to Functional Thinking by Katie Miller at CampJS
A Facebook open source project for simplifying remote data access.
Arguably the most popular Haskell project around for now. This is a web application that gives your PostgreSQL database a REST API. It’s written in Haskell. I find this to be an interesting project since it is something that most people wouldn’t consider using Haskell for.
Everyone knows about Jekyll, the Ruby static site generator. Hakyll is a Haskell implemented static site generator.