System Overlord

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

Building a Home Lab for Offensive Security & Security Research

24 Oct 2017 in Security (Reading time: 17 minutes)

When I wrote my “getting started” post on offensive security, I promised I’d write about building a lab you can use to practice your skillset. It’s taken a little while for me to get to it, but I’m finally trying to deliver.

Much like the post on getting started, I’m not claiming to have all the answers. I’ll again be focusing on an environment that helps you build a focus in the areas I most work in – penetration testing, black box application security, and red teaming. (And if you’re wondering about the difference between a penetration test and red team, there will be a post for that too – I promise they’re very different.)

As usual, I encourage others to share their thoughts with me via Twitter or email.

Use Cases

There’s a few different things you might want to do with your lab. I’ll list some of the more common things I do with my lab setups below, because how you use it will influence how you set it up.

Full Environment Simulation

This is probably the most complex option, but also one of the most useful, especially if you’re just getting into penetration testing. In this case, you want to build out a full replica of a target environment, but entirely owned and controlled by you (so it’s legal to play around in).

If you’re looking to practice for a particular engagement/environment, you’ll want to reproduce your target environment as closely as possible. If you want a general lab to practice pentesting, you can simulate a fairly typical corporate environment.

Application Security Research

When doing application security research, your goals are quite a bit different from pentesting. In application security, you generally want to be able to instrument the application as much as you can. Most critically, you want to be able to intercept all of the network traffic to/from the application, attach a debugger to the application, and otherwise control the environment. Ideally, you also want to keep the miscellaneous noise to a minimum, so using a system with nothing else going on can be helpful.

Depending on the application, you might want a web proxy like Burp Suite, or a packet capture tool like Wireshark. In either case, you can either run your proxy locally or use a router to direct traffic through.

For mobile application testing, you can use an emulator, or you might want a cheap access point on your lab network to which you can connect a real device.

Tool Testing

Tool testing will have all kinds of different requirements depending on what tool you want to test. It’s hard to give more advice than to think about the environment the tool is designed to test/exploit/assess.

Hardware

There’s a number of options for where to run your lab environment, and they all have pros and cons, and in reality, you’re likely to eventually use some combination of them. I’ll give a quick rundown of the options and pros/cons of each below. There’s no single right or wrong answer, because it will depend on a variety of factors:

  • Your budget
  • What you already have
  • How extensive you want your lab to be
  • The specific skills you want to work on
  • Space available/spousal approval

Hardware Option A: Just Use the Cloud

Obviously, we’re moving into a “Cloud” world (for better or for worse). Consequently, it’s not surprising that a lab in the cloud might be a popular choice, but it comes with a lot of tradeoffs.

Unless you know what you want to do fits the cloud model well, or you absolutely don’t have a better option, beginners might find one of the other options better suited to their needs.

For most of the tasks I’ve described, you’ll want to choose a provider that allows you to have a private virtual network between hosts, so that your traffic is segregated from other customers. You’ll also need to carefully read the terms of service to ensure anything you do is within bounds – just because you’re testing against your own VMs doesn’t mean you can do anything you want on somebody else’s infrastructure.

You’ll also want to be sure to figure out what kind of connectivity you can get into your lab for the types of attacks you want to perform. Some attacks require that you have a host on the same network (not routed) as your target, so you’ll either need an L2 VPN (e.g., OpenVPN in a bridged configuration) or you’ll need to set up a box in your lab dedicated to being the ‘attacker’ machine.

Operating System choice is also key – if you want to practice on Windows domains, a Cloud provider that’s only selling Linux VPS won’t do you a lot of good. Even those that offer Windows might not offer Windows client systems, but that’s not terrible – you can often treat a Windows Server as a client anyway, it will just take some extra configuration.

For a lot of my testing, I use DigitalOcean, but they’re a Linux-only environment, so better for Application testing than for full environment simulation.

Pros:

  • Easy to spin up
  • Takes no space
  • No large initial investment (cost)

Cons:

  • Ongoing cost
  • Might be limited by ToS
  • More difficult to manage
  • Strange configurations are harder to build

Hardware Option B: Decent Laptop/Desktop

So, “decent” is subjective, but there are a few guidelines here:

  • You need support for hardware virtualization. (Intel VT) Consequently, some Celeron-, Atom-, and Pentium-branded processors won’t make the cut, as well as some of the AMD A-series. Any Core i3, i5, or i7 should do the trick.
  • Memory is critical. VMs love memory. Count on at least 2GB for a Windows Client, 4GB for a Windows Server, and 1GB for a minimal Linux install, but more is always better. I look for at least 16GB of RAM in a laptop if I’m going to be running a lot of VMs.
  • The hard drive requirements aren’t massive, but you’ll want more than something like a 128GB SSD. I use a 1TB Samsung 850 EVO, but that might be a bit overkill for most users.

There are obviously a lot of laptops that meet the minimums you’d want, so the rest is about making sure you’re comfortable using it. A good screen and a good keyboard are key in that. These days, you really shouldn’t settle for 720p screens (1368x768), so 1920x1080 (1080p) is about your starting point there.

Pros:

  • Cheapest, if you already have one usuable
  • Portable (laptop)

Cons:

  • Can be quite expensive
  • Least flexible option
  • Might not support enough VMs for some configurations

Hardware Option C: Dedicated Hardware

This is the most serious, but also the most flexible option. Having a lab on dedicated hardware will cost, but it allows you to build out whatever you want.

There’s a few approaches here. Simplest is basically a standard desktop build, but instead of running a full desktop OS on it, you can run ESXi, Xen, Proxmox, or another Hypervisor build. More complex, you can have a NAS and use something like an Intel NUC or other small form factor PC to provide your compute power.

Most people will opt for either a desktop or the small form factor options, but others can spare the space (and cost) of a small home rack with a larger NAS and a few rack-mounted servers. Of course, you can really go to an extreme: check out /r/homelab to see what some people have done (though not necessarily for a security-focused homelab).

Pros:

  • Most Flexible
  • Most Powerful

Cons:

  • Potentially very expensive
  • Can consume lots of power/space

Software

I’ll be describing a generic software setup, but you might need to adjust based on how you’ve setup the hardware/hosting for your lab environment.

Networking

I suggest placing your machines on an isolated network. There’s several different ways you can do this:

  • Private networking provided by your cloud provider (obviously only for a lab in the cloud)
  • A virtual network in your virtualization software
  • A separate physical network switch (only usuable if your hardware is dedicated to your lab)
  • A VLAN on a managed network switch

Whichever way you choose will keep your “normal” traffic apart from your lab traffic, and prevent you from causing trouble for anyone else who might use your network (spouses, roommates, significant others, guests, etc.).

I like to put a router between the two networks to give internet access to your lab (obviously be careful that anything malicious stays within the lab) and to provide remote access (via OpenVPN). I currently use pfSense to provide this, which you can run on bare metal, or run as a Virtual Machine.

Operating Systems

My lab setup has varied over time, but I’d say the “common ground” of a lab is something that replicates your typical enterprise environment. Typically, this will include:

  • Windows Servers (typically a Domain Controller)
  • Linux Servers (typically Application Servers)
  • Windows Clients (various versions)

Optionally you may want to consider:

  • Linux Desktops
  • OS X
  • Mobile devices (iOS, Android)

Obviously, Linux can be had for free, but for Windows, an MSDN subscription can go a long way, or you can use some versions for a 30 day testing period. (Make sure you follow the license terms!)

Applications

What applications you run will largely depend on what you want to try/practice/test, but there’s a few things that are pretty universal. I strongly recommend running a Windows domain with domain-joined clients, as most enterprise environments will fit that model.

You’ll also need the applications that are necessary to make a network run – DNS and DHCP. Don’t just forward these upstream, but really set them up to model a typical enterprise. DNS will be an interesting exercise to have working properly in your test lab.

Beyond that, you might want to consider:

  • SMB File Share (Windows and/or Linux)
  • Web Applications
    • Wordpress/Blogging Software
    • Shopping Carts
    • Help Desk Ticketing
  • Remote Desktop/VNC
  • Database Servers (try running on a different host than the webapps)

If you want to do typical penetration testing, try installing some applications that are not the current version. Don’t look too carefully at the list of changes/existing vulnerabilities to leave yourself some challenge.

Security Software

Depending on the testing you want to do, you may want to set up some defensive security software. For example, setting up Snort or Bro will help you see how defenders see your attacks and discover which are noisy and which are quiet. Adding Splunk will help you aggregate logs, and is another way to understand how defenders work.

You can also add some AV solutions to see whether (or not) your attacks or payloads are protected against by various tools. Unfortunately, I don’t think there are any free binary whitelisting solutions for Windows, so you won’t be able to try out bypasses on that.

Pre-made VMs (Targets)

There’s a few well-known pre-made VMs with vulnerable applications, such as:

You can also consider including some pre-made vulnerable VMs from sources like VulnHub or build random ones with SecGen.

Pre-made VMs (Tools)

There’s a couple of good options (and this is not an exhaustive list) for pre-made tool VMs. Obviously you have Kali Linux for offensive tools and penetration testing, but you can also use Security Onion for the defensive side – intrusion detection and network security monitoring.

My Personal Setup

My personal setup is not necessarily the right way to do things (in fact, I have a lot I’d like to change) but I include it as an example for others of how a lab setup can be used in practice.

Hardware

My main lab setup is a desktop build with:

This all connects to a ZyXEL GS1900-16 managed switch so I can have separate VLANs for lab and regular network access. Possibly overkill, but it works well for me and was a great opportunity to learn about VLANs, trunking, 802.1q, etc.

I have a dedicated lab SSID on my WiFi access point (easily done if you’re running something like OpenWRT) on a vlan that comes back into my lab environment, so I can attach wireless devices (IoT, mobile, etc.) and segregate their traffic.

I’ve also added a couple of Raspberry Pis and some other hardware over time for specific cases. I keep a previous-generation cell phone for research in the lab as well. (Because I’d rather not install sketchy apps on my regular phone.)

None of this is particularly high end hardware, and it’s only a few hundred dollars worth of hardware. I’ve also accumulated it over several years, so this is an example of how you can start simple and grow from there. For example, I used to use old 500GB-1TB hard drives, and the network switch is also a relatively recent addition.

OS/Software

My host OS is Debian stable, using KVM for virtualization, and with software bridges trunked out to the GS1900 switch. I also have some internal-ony bridges for other activities.

I have a virtual pfSense install as a router/firewall between the lab and the rest of my network. It provides OpenWRT when I need to be “on” the network, but most of the time, I just route my traffic through. Currently, the pfSense system hosts the DHCP and DNS servers, but I’ve thought about switching to the domain controllers (like you really should, at least for DNS).

I do have a Domain Controller on Server 2016, and a couple of Windows Clients. MSDN licenses are a great option for this. Most of my applications are on some variant of Linux, often an older version of Ubuntu (because the application is known to run well in this environment).

Other Resources

Conclusion

I hope this has been useful to those of you looking for a home lab to sharpen your security skills. I wanted to do more of a “recipe”, but given how much variation there is in possible setups, presenting all the options seemed to make more sense. Let me know on Twitter if you’re interested in a recipe for a particular setup. Good luck, have fun, and stay legal!

Getting Started in Offensive Security

18 Sep 2017 in Security (Reading time: 12 minutes)
Information security is a large field with a variety of required skillsets and backgrounds. It also is an exciting field with many people interested in getting started. These are my thoughts on getting into the offensive security space.

Read More...

Review of HackerBoxes 0021: Hacker Tracker

11 Aug 2017 in Electronics (Reading time: 7 minutes)

HackerBoxes is a monthly subscription service for hardware hackers and makers. I hadn’t heard of it until I was researching DEF CON 25 badges, for which they had a box, at which point I was amazed I had missed it. They were handing out coupons at DEF CON and BSidesLV for 10% off your first box, so I decided to give it a try.

Hacker Tracker

First thing I noticed upon opening the box was that there’s no fanfare in the packaging or design of the shipping. You get a plain white box shipped USPS with all of the contents just inside. I can’t decide if I’m happy they’re not wasting material on extra packaging, or disappointed they didn’t do more to make it feel exciting. If you look at their website, they show all the past boxes with a black “Hacker Boxes” branded box, so I don’t know if this is a change, or the pictures on the website are misleading, or the influx of new members from hacker summer camp has resulted in a box shortage.

I unpacked the box quickly to find the following:

  • Arduino Nano Clone
  • Jumper Wires
  • Small breadboard
  • MicroSD Card (16 GB)
  • USB MicroSD Reader
  • MicroSD Breakout Board
  • u-blox NEO 6M GPS module
  • Magnetometer breakout
  • PCB Ruler
  • MicroUSB Cable
  • Hackerboxes Sticker
  • Pinout card with reminder of instructions (aka h4x0r sk00l)

If you’ve been trying to do the math in your head, I’ll save you the trouble. In quantity 1, these parts can be had from AliExpress for about $30. If you’re feeling impatient, you can do it on Amazon for about $50. Of course, the value of the parts alone isn’t the whole story: this is a curated set of components that builds a project, and the directions they provide on getting started are part of the product. (I just know everyone wanted to know the cash value.)

Compared to some of their historical boxes, I’m a little underwhelmed. Many of their boxes look like something where I could do many things with the kit or teach hardware concepts: for example, “0018: Circuit Circus” is clearly an effort to teach analog circuits. “0015 - Connect Everything” lets you connect everything to WiFi via the ESP32. Even when not multi-purpose, previous kits have included reusable tools like a USB borescope or a Utili-Key. Many seem to have an exclusive “fun” item, like a patch or keychain, in addition to the obligatory HackerBoxes sticker.

In contrast, the “Hacker Tracker” box feels like a unitasker: receive GPS/magnetometer readings and log them to a MicroSD card. Furthermore, there’s not much hardware education involved: all of the components connect directly via jumper wires to the provided Arduino Nano clone, so other than “connect the right wire”, there’s no electronics skillset to speak of. On the software side, while there are steps along the way showing how each component is used, a fully-functional Arduino sketch is provided, so you don’t have to know any programming to get a functional GPS logger.

Overall, I feel like this kit is essentially “paint-by-numbers”, which can either be great or disappointing. If you’re introducing a teenager to electronics and programming, a “paint-by-numbers” approach is probably a great start. Likewise, if this is your first foray into electronics or Arduino, you should have no trouble following along. On the other hand, if you’re more experienced and just looking for inspiration of endless possibilities, I feel like this kit has fallen short.

There’s one other gripe I have with this kit: there are headers on the Arduino Nano clone and the MicroSD breakout, but the headers are not soldered on the accelerometer or GPS module. At least if you’re going to make a simple kit, make it so I don’t have to clean off the soldering station, okay?

So, am I keeping my subscription? For the moment, yes, at least for another month. Like I said, I’ve been impressed by past kits, so this might just be an off month for what I’m looking for. I don’t think this kit is bad, and I’m not disappointed, just not as excited as I’d hoped to be. I might have to give Adabox a try though.

As for the subscription service itself: it looks like their web interface makes it easy to skip a month (maybe you’re travelling and won’t have time?) or cancel entirely. I’m not advocating cancelling, but I absolutely hate when subscription services make you contact customer service to cancel (just so they can try to talk you into staying longer, like AOL back in the 90s). The site has a nice clean feel and works well.

If anyone from HackerBoxes is reading this, I’ll consolidate my suggestions to you in a few points:

  • Hook us up with patches & more stickers! Especially a sticker that won’t take 1/4 of a laptop. (I love the sticker from #0015 and the patch from #0018.)
  • Don’t have the only soldering be two tiny header strips. Getting out the soldering iron just to do a couple of SPI connections is a bit of a drag. Either do a PCB like #0019, #0020, etc., or provide modules with headers in place. (If it wasn’t for the soldering, you could take this kit on vacation and play with just the kit and a laptop!)
  • Instructables with more information on why you’re doing what you’re doing would be nice. Mentioning that there’s a level shifter on the MicroSD breakout because MicroSD cards run at 3.3V, and not the 5V from an Arduino Nano, for example.
  • Including a part that requires a warning about you (the experts) having had a lot of problems with it in an introductory kit seems like a poor choice. A customer with flaky behavior won’t know if it’s their setup, their code, or the part.

Overall, I’m excited to see so much going into STEM education and the maker movement, and I’m happy that it’s still growing. I want to thank HackerBoxes for being a part of that and wish them success even if I don’t turn out to be their ideal demographic.

Hacker Summer Camp 2017: Lessons Learned

07 Aug 2017 in Security (Reading time: 7 minutes)

In addition to taking stock of how things went at Hacker Summer Camp, I think it’s important to examine the lessons learned from the event. Some of these lessons will be introspective and reflect on myself and my career, but I think it’s important to share these to encourage others to also reflect on what they want and where they’re going.

Introspections

It’s still incredibly important to me to be doing hands-on technical work. I do a lot of other things, and they may have significant impact, but I can’t imagine taking a purely leadership/organizational role. I wouldn’t be happy, and unhappy people are not productive people. Finding vulnerabilities, doing technical research, building tools, are all areas that make me excited to be in this field and to continue to be in this field.

I saw so many highly-technical projects presented and demoed, and these were all the ones that made me excited to still be in this field. The IoT village, in particular, showed a rapidly-evolving highly technical area of security with many challenges left to be solved:

  • How do you configure devices that lack a user interface?
  • How do you update devices that users expect to run 24/7?
  • How do you build security into a device that users expect to be dirt cheap?
  • What are the tradeoffs between Bluetooth, WiFi, 802.15.4, and other radio techs?

Between these questions and my love of playing with hardware (my CS concentration was in embedded systems), it’s obvious why I’ve at least slightly gravitated towards IoT/embedded security.

This brings me to my next insight: I’m still very much a generalist. I’ve always felt that being a generalist has hamstrung me from working on cool things, but I’m beginning to think the only thing hamstringing me is me. Now I just need to get over the notion that 0x20 is too old of an age for cool security/vulnerability research. I’m focusing on IoT and I’ve managed to exclude certain areas of security in the interests of time management: for as fascinating as DFIR is, I’m not actively pursuing anything in that space because it turns out time is a finite quantity and spreading it too thin means getting nowhere with anything.

Observations

Outwardly, I’m happy that BSidesLV and DEF CON both appear to have had an increasingly diverse attendance, though I have no idea how accurate the numbers are given their methodology. (To be fair, I’m super happy someone is trying to even to figure this out in the chaos that is hacker summer camp.) The industry, and the conferences, may never hit a 50/50 gender split, but I think that’s okay if we can get to a point where we build an inclusive meritocracy of an environment. Ensuring that women, LGBTQ, and minorities who want to get into this industry can do so and feel included when they do is critical to our success. I’m a firm believer that the best security professionals draw from their life background when designing solutions, and having a diverse set of life backgrounds ensures a diverse set of solutions. Different experiences and different viewpoints avoids groupthink, so I’m very hopeful to see those numbers continue to rise each year.

I have zero data to back this up, but observationally, it seemed that more attendees brought their kids with them to hacker summer camp. I love this: inspiring the next generation of hackers, showing them that technology can be used to do cool things, and that it’s never too early to start learning about it will benefit both them (excel in the workforce, even if they take the hacker mindset to another industry) and society (more creative/critical thinkers, better understanding of future tech, and hopefully keeping them on the white hat side). I don’t know how much of this is a sign of the maturing industry (more hackers have kids now), more parents feel that it’s important to expose their kids to this community, or maybe just a result of the different layout of Caesar’s, leading to bad observations.

Logistics

There were a few things from my packing list this year that turned out to be really useful. I’m going to try to do an updated planning post pair (e.g., one far out and one shortly before con) for next year, but there’s a few things I really thought were useful and so I’ll highlight them here.

  • An evaporative cooling towel really helps with the Vegas heat. It’s super lightweight and takes virtually no space. Dry, its useful as a normal towel, but if you wet it slightly, the evaporating water actually cools off the towel (and you). Awesome for 108 degree weather.
  • An aluminum water bottle would’ve been nice. Again, fight the dehydration. In the con space, there’s lots of water dispensers with at least filtered water (Vegas tap water is terrible) plus the SIGG bottles are nice because you can use a carabiner to strap it to your bag. I like the aluminum better than a polycarbonate (aka Nalgene) because it won’t crack no matter how you abuse it. (Ok, maybe it’s possible to crack aluminum, but this isn’t the Hydraulic Press Channel.)
  • RFID sleeves. I mentioned these before. Yes, my room key was based on some RFID/proximity technology. Yes, a proxmark can clone it. Yes, I wanted to avoid that happening without my knowing.

For some reason, I didn’t get a chance to break out a lot of the hacking gear I brought with me, but I’ll probably continue to bring it to cons “just in case”. I’m usually checking a bag anyway, so a few pounds of gear is a better option than regretting it if I want to do something.

Conclusion

That concludes my Hacker Summer Camp blog series for this year. I hope it’s been useful, entertaining, or both. Agree with something I said? Disagree? Hit me up on Twitter or find me via other means of communications. :)

Hacker Summer Camp 2017: DEF CON

05 Aug 2017 in Security (Reading time: 6 minutes)

DEF CON, of course, is the main event of Hacker Summer Camp for me. It’s the largest gathering of hackers in the world, and it’s the only opportunity I get to see some of the people I know in the industry. It’s also the most hands-on of all of the conferences I’ve ever attended, and the people running the villages clearly know their stuff and are super passionate about their area. Nowhere do I see so much raw talent and excitement for the hacker spirit as at DEF CON.

This year was the first year at Caesar’s Palace and quite frankly, it showed. Traffic control reminded me of the first year at Bally’s/Paris: as best as they could do without any data, but still far from optimal. Additionally, Dark Tangent pointed out that they were expecting 6% growth, but ended up closer to 20%. That’s thousands extra. The rule that they do not sell out and everyone gets through the door is not without its downsides.

Overall, this year was incredible for me personally. Though I attended no main track talks, I made it to a couple of Sky Talks and some village talks, as well as a bunch of village activities. I met a bunch of interesting people who are working on interesting technical things, which is great because it reminds me why I got into this industry in the first place and what I want to be doing in the future.

The IoT village was excellent, but I wish I had gotten to it earlier to participate in the IoT CTF – it looked like a lot of fun, and their physical target range wasn’t something you see everyday. They had everything from cheap bluetooth devices to the Google Home and Amazon Alexa, and I believe this is a reflection of where we’ll see the future growth in security – the IoT isn’t a passing fad, and we’ll have millions of low-cost devices deployed and not properly managed. There’s no time like the present to get security to the front and center of the IoT device design process.

In previous years, I’d always played in the Capture the Packet contest. This year I opted out, despite having a bye in the first round, because there was so much going on and because it had consumed too much of my time at DEF CON 24. I don’t regret this decision, but it is something I missed slightly. In fact, it ended up that I never even set foot in the packet capture village! (I guess that’s what happens to villages at the end of halls?)

The “linecon” joke was never more accurate than this year – there was a line for everything! Not only did every talk have lines, but there were lines to get into the Biohacking Village, the Swag line was long (where was Hacker Stickers with our official unofficial swag?), even the line for Mohawkcon was ridiculous! (Maybe next year I just need to get a mohawk before I go there – it’s not like I don’t donate to the EFF anyway.) I’m sure this is a combination of many factors, including the growth of the community, the new venue, and the fact that it wouldn’t be DEF CON without linecon.

The DEF CON artwork is not something I normally write about, largely because I’m no artist and I barely have an eye for, well, anything, but I really thought the art was excellent this year. I so desperately wanted to rip one of the posters off the wall next to the escalators! (I have hopes one of them might appear in a charity auction at some point, but I didn’t see it at con.)

Caesar’s as a venue was okay – there was noticably more space, but figuring out how to get between some of the areas was not crystal clear. A lot of that was on me – I should’ve done more recon of the con area. (Look for a “lessons learned” post coming soon.) My hotel room was awesome though, and in the tower right above the con space, so I had that going for me. Fingers crossed to get in the same tower next year.

Dual Core

Dual Core had an outstanding show on the Friday Night lineup. I don’t care what DEF CON calls the headliner, Dual Core is always the headliner for my music tastes. I’ve seen him perform live at least once at every DEF CON and at dozens of other events (Southeast Linux Fest, DerbyCon, etc.), and I just don’t think it would be a full con without seeing him.

Mad props to DT and all the DEF CON Goons and organizers who work so hard to put the event together. No matter how much chaos there may be, I’ve had a great time every year, and I wouldn’t miss it for the world. That’s just a part of the World’s Biggest Hacker Convention.