System Overlord

A blog about security engineering, research, and general hacking.

On Deep Work

24 Jun 2018 in Life (Reading time: 6 minutes)

I recently stumbled upon Azeria’s blog post The Importance of Deep Work & The 30-hour Method For Learning a New Skill, and it seriously struck a chord with me. Over the past year or so, I’ve struggled with a lack of personal satisfaction in my life and my work. I tried various things to address the issue, but could not figure out a root cause until I read her article, and then it clicked with me.

Even though I was constantly busy at work, I never felt like I was getting the things done that mattered to me: security research, tackling difficult technical challenges, focused security work. Instead I was constantly in meetings, switching tasks, dealing with email, and other work that felt like I was just barely keeping afloat at the office.

I’ve since read Cal Newport’s Deep Work: Rules for Focused Success in a Distracted World, and now I have an understanding of why I’ve had these feelings and, much more importantly, what to do about them. I’ll start by saying that the book is not one I ever thought I would be reading. It sounds like, and is, half self-help book and half business strategy book, neither of which are categories I usually give much attention. But Newport is also a professor of Computer Science, the book was recommended by Azeria, and I felt like I needed to try something different, so I gave it a shot.

The first third of the book is spent defining “deep work” and “shallow work” and convincing you that it’s worth pursuing “deep work”. I nearly gave up on the book at this point because my unhappiness with how things were already going had already convinced me of the value of deep work, so I figured I didn’t need a book to tell me I was doing things wrong, but I stuck with it, and I think it ended up being worth it.

Deep work is creative work that produces new value and requires that your stretch your brain to its limits. It is also the work that is best done in a state of flow (uninterrupted work focused entirely on one task at hand), and is the work that helps to build and grow the pathways in the brain. In my case, deep work includes things like security research, tool building, and learning new skills.

Shallow work is work that doesn’t require the full use of your brain, or that can be easily interrupted and resumed later, such as logistical tasks. In my case, this includes “doing email”, most meetings, and a lot of the collaboration I do with team mates. This is not to dismiss shallow work as unimportant, but it is different and done with a different mindset. It is also easier to get to shallow work with less mental friction, which leads to a tendency to go to shallow work.

All of this discussion is useless to me if I don’t actually make some changes based on what I’ve learned. I also don’t expect the “deep work” mindset to be a silver bullet to fix the problems I’m having. Some of the sources are likely outside that position, and going “all in” on the four rules set out by Newport would be difficult in my current corporate culture.

I am going to try some things though:

  • Schedule at least 3 blocks of 3+ hours a week for Deep Work. During this time period, I will not check email, respond to (or read) instant messages, etc.
  • Reduce the frequency with which I check email to ~3 times per day.
  • Use separate browser windows for deep work, so I can hide the windows that have the distractions.
  • Schedule time for personal projects as deep work.

Some problems I’ll still have:

  • My team works in a highly collaborative fashion. Realtime communication is expected. I’ll need to find some way to sequester myself.
  • I work in an open office floorplan, which has so many distractions that even shallow work is difficult. Finding somewhere to hide and do “deep work” means sacrificing my desktop and it’s large screens.
  • A corporate culture where anyone can schedule a meeting anytime and expect you to show up.

I’m going to try an increased effort on deep work and following some of the principles from the book, as well as better efforts to track how I spend my time. I’ll report back in 6 months time on whether or not I feel more productive, am happier with my work, and have actually been able to stick to these things.

Pros vs Joes CTF: The Evolution of Blue Teams

19 Jun 2018 in Security (Reading time: 10 minutes)

Pros v Joes CTF is a CTF that holds a special place in my heart. Over the years, I’ve moved from playing in the 1st CTF as a day-of pickup player (signing up at the conference) to a Blue Team Pro, to core CTF staff. It’s been an exciting journey, and Red Teaming there is about the only role I haven’t held. (Which is somewhat ironic given that my day job is a red team lead.) As Blue teams have just formed, and I’m not currently attached to any single team, I wanted to share my thoughts on the evolution of Blue teaming in this unique CTF. In many ways, this will resemble the Blue Team player’s guide I wrote about 3 years ago, but will be based on the evolution of the game and of the industry itself. That post remains relevant, and I encourage you to read it as well.

Basics

Let’s start by a refresher of the basics, as they exist today. The gameplay is a two day game, with teams being completely “blue” (defensive) on the first day, and teams moving to a “purple” stance (defending their own network, and able to attack each other as well) on the second day. During the first day, there’s a dedicated red team providing the offensive incentive to the blue teams, as well as a grey team representing the users/customers of the blue team services.

Each blue team consists of eight players and two pros. The role of the pros is increasingly mentorship and less “hands on keyboard”, fitting with the Pros v Joes mission of providing education & mentorship.

Scoring

Scoring was originally based entirely on Health & Welfare checks (i.e., service up and responding) and flags that can be captured from the hosts. Originally, there were “integrity” flags (submitted by blue) and offense flags (submitted by red).

As of 2017, scoring included health & welfare (service uptime), beacons (red cell contacting the scoreboard from the server to prove that it is compromised), flags (in theory anyway), and an in-game marketplace that could have both positive and negative effects. 2018 scoring details have not yet been released, but check the 2018 rules when published.

The Environment

The environment changes every year, but it’s a highly heterogenous network with all of the typical services you would find in a corporate network. At a minimum, you’re likely to see:

  • Typical web services (CMS, etc.)
  • Mail Server
  • Client machines
  • Active Directory
  • DNS Server

The operating systems will vary, and will include older and newer OSs of both Windows and Linux varities. There has also always been a firewall under the control of each team segregating that team’s network from the rest of the network. These have been both Cisco ASA firewalls as well as pfSense firewalls.

Each player connects to the game environment using OpenVPN based on configurations and credentials provided by Dichotomy.

Preparation

There has been an increasing amount of preparation involved in each of the years I have participated in PvJ. This preparation has essentially come in two core forms:

  1. Learning about the principles of hardening systems and networks.
  2. Preparing scripts, tools, and toolkits for use during the game.

Fundamentals

It turns out that a lot of the fundamental knowledge necessary in securing a network are just basically system administration fundamentals. Understanding how the system works and how systems interact with each other provides much of the basics of information security.

On both Windows and Linux, it is useful to understand:

  • How to install & update software and operating system updates
  • How to change permissions of files
  • How to start and stop services
  • How to set up a host-based firewall
  • Basic Shell Commands
  • User administration

Understanding basic networking is also useful, including:

  • TCP vs UDP
  • Stateful vs stateless firewalls
  • Using tcpdump and Wireshark to debug and understand network traffic

Knowing some kind of scripting language as well can be very useful, especially if your team prepares some scripts in advance for common operations. Languages that I’ve found useful include:

  • Bash
  • Powershell
  • Python

Player Toolkit

Obviously, if you’re playing in a CTF, you’ll need a computer. Many of the tools you’ll want to use are either designed for Linux or are more commonly used on Linux, so almost everyone will want to have some sort of a Linux environment available. I suggest that you use whatever operating system you are most comfortable with as your “bare metal” operating system, so if that’s Windows, you’ll want to run a Linux virtual machine.

If you use a Macbook (which seems to be the most common choice at a lot of security conferences), you may want both a Windows VM and a Linux VM, as the Windows Server administration tools (should you choose to use them) only run on Windows clients. It’s also been reported that TunnelBlick is the best option for an OpenVPN Client on MacOS.

As to choice of Linux distribution, if you don’t have any personal preference, I would suggest using Kali Linux. It’s not that Kali has anything you can’t get on other distributions, but it’s well-known in the security industry, well documented, and based on Debian Linux, which makes it well-supported and a close cousin of Ubuntu Linux that many have worked with before.

There are some tools that are absolutely necessary and you should familiarize yourself with them in advance:

  • nmap for network enumeration
  • SSH for connecting to Linux Machines
  • RDP for connecting to Windows Machines
  • git, if your team will use it for managing configurations or scripts
  • OpenVPN for connecting to the game environment

Other tools you’ll probably want to get some experience with:

  • metasploit for going offensive
  • Some kind of directory enumeration tool (Dirbuster, WebBorer)
  • sqlmap for SQL injection

Useful Resources

Game Strategy

Every team has their own general strategy to the game, but there are a few things I’ve found that seem to make gameplay go more smoothly for the team:

  • During initial hardening, have one team member working on the firewall. Multiple players configuring the firewall is a recipe for lockouts or confusion.
  • Communicate, communicate, communicate. Ask questions when needed, and make sure it’s clear who’s working on what.
  • Document everything you do. You don’t need to log every command (though it’s not a bad idea), but you should be able to answer some questions about the hosts in your network:
    • What hosts exist?
    • What are the passwords for the accounts?
    • Have the passwords been changed from the defaults?
    • What services are scored?
    • What hardening steps have been applied?

Dos & Don’ts

  • DO make sure you have a wired ethernet port on your laptop, or a USB to ethernet adapter and an ethernet cable.
  • DO make sure you’ve set up OpenVPN on your host OS (not in a VM) and you’ve tested it before game day.
  • DO make sure you’ve read the rules. DON’T try to cheat, Gold team will figure it out and make you pay.
  • DO make an effort to try new things. This game is a learning experience, and you miss 100% of the shots you don’t take.
  • DO ask questions. DON’T be afraid of looking stupid – everyone in the security industry has things to learn, and the whole point of this event is that you can learn. You might even stump the pros.

Making the Most of It

Like so many things in life, the PvJ CTF is a case where you get out of it what you put into it. If you think you can learn it all by osmosis or being on the same team but without making effort, it’s unlikely to work out. PvJ gives you an enthusiastic team, mentors willing to help, and a top-notch environment to try things out that you might not have the resources for in your environment.

To all the players: Good luck, learn new things, and have fun!

Hacker Summer Camp 2018: Prep Guide

26 May 2018 in Security (Reading time: 49 minutes)
Hacker Summer Camp is the combination of DEF CON, Black Hat USA, and BSides Las Vegas that takes place in the hot Las Vegas sun every summer, along with all the associated parties and side events. It's the largest gathering of hackers, information security professionals and enthusiasts, and has been growing for 25 years. In this post, I'll present my views on how to get the most out of your 2018 trip to the desert.

Read More...

How the Twitter and GitHub Password Logging Issues Could Happen

03 May 2018 in Security (Reading time: 7 minutes)

There have recently been a couple of highly-publicized (at least in the security community) issues with two tech giants logging passwords in plaintext. First, GitHub found they were logging plaintext passwords on password reset. Then, Twitter found they were logging all plaintext passwords. Let me begin by saying that I have no insider knowledge of either bug, and I have never worked at either Twitter or GitHub, but I enjoy randomly speculating on the internet, so I thought I would speculate on this. (Especially since the /r/netsec thread on the Twitter article is amazingly full of misconceptions.)

Read More...

BSidesSF CTF 2018: Coder Series (Author's PoV)

21 Apr 2018 in Security (Reading time: 14 minutes)

Introduction

As the author of the “coder” series of challenges (Intel Coder, ARM Coder, Poly Coder, and OCD Coder) in the recent BSidesSF CTF, I wanted to share my perspective on the challenges. I can’t tell if the challenges were uninteresting, too hard, or both, but they were solved by far fewer teams than I had expected. (And than we had rated the challenges for when scoring them.)

The entire series of challenges were based on the premise “give me your shellcode and I’ll run it”, but with some limitations. Rather than forcing players to find and exploit a vulnerability, we wanted to teach players about dealing with restricted environments like sandboxes, unusual architectures, and situations where your shellcode might be manipulated by the process before it runs.

Read More...