RaspPi Auto-Enumerator Part 1: Designing a System

Last Updated: 2018-12-22

Introduction

With the possible exception of the Arduino and the obvious exception of laptop/desktop computers, there is no electronic device more synonymous with hacker culture than the Raspberry Pi. These little ARM computers were developed for low-cost, reasonable-performance computing with the third world in mind, but they've become a hit with hackers, skids, and people who just want to play video games from twenty years ago alike. Rare's the individual in our community without one in the drawer somewhere, and in my case, I thought I might do something actually hackish with one - build an automated enumeration system.

This autumn, I've fallen into the challenges at Hack The Box in a big way. However, like many of us starting out I find the process of enumerating a new host tedious. Since I take my laptop (my only computer) with me, it was getting hard to think of ways to enumerate hosts that didn't eat into my evening hours in a bad way. Running those same tests from my server, Polaris, seemed to be a bad idea, so it occurred to me to take the raspberry pi collecting dust in the living room and turn that into a host pre-enumerator.

This guide is, of course, going to touch on the process of actually building such a thing. But more generally, the series of guides I'll be writing based on this project are more generally a breakdown of how I like to think of system-scale projects like the Tapestry-Loom interaction, my semi-abandoned MUD project, and the VM lab I rolled out last summer.

I also want to be clear - this product isn't new, original, and likely won't be the last, either. There are more fully-featured, existing penetration testing images for the raspberry pi. I believe Kali even comes precompiled for ARM now, with an image designed explicitly for the pi. This project is specifically for creating the Host Pre-Enumeration System that I need, for my purpose, at this moment.

Step 0: Establishing Clear Aims

If you're anything like most of us, you were practically born with a case of Feeping Creaturitis. Hackish Nature, for me, has always been synonymous with a drive toward improvement, and with that comes the burden of having to remember to build a tool most suited to task. Generalizing solutions is useful if you're building a product for sale. For something like this though, and for most bespoke engagements, you need to do The Thing, and just that.

A big help in countering creeping featuritis is taking the time to pre-define a project's scope. You're going to have some scope creep as things you forget to consider - like, say, including word-lists - pop up, but for the most part, a good thorough brainstorm at the beginning of a project like this can get most of the feature creep out of the way early.

This can also help figure out a budget, not just in terms of dollars, but time. In our case this project will be free as in beer - I already own the Pi and the software I intend to use is all available gratis-at-least (and possibly libris as well).

In our case, the goal is simple. A plug-and-play solution for doing basic host enumeration against a given HTB subnet, with a demand-reporting feature for moving the data obtained between the enumerator and the main working machine. Fundamentally this means a relatively simple project. While I could likely achieve all of its goals in a month of spare evenings, I'm going to be generous myself and alot a quarter before I get truly irritable. It's not paid work and I must allow for the wanderings of the mind and my other projects.

Step 1: Reduce the Project to its Component Parts

Though dated, David Allen's book, Getting Things Done, detailed a system of productivity management for knowledge-work (such as this) that revolved around the idea of breaking projects into their smallest component parts. Like many things, this has been a gross over-simplication of the idea, but as a general rule I've found the practice of breaking projects down in this way to be very helpful. Rome was built one structure at a time, and those structures, one member at a time. So goes every other project.

Existing Products

As a recovering chef, I find it very hard not to take every project down to the bare metal, so to speak. There's no need for us to re-invent ARM assembly or operating systems, nor indeed a vast majority of the tools we intended to use, the dependancies of those tools, and other data-sets already in existance. For this project, I intend to use the following:

  • Raspbian, a Debian-based linux distro made for use with the Raspberry Pi hardware
  • golang, the compiler for the Go Programming Language, which we need to use to compile gobuster from source.
  • Python 3.5, a popular interpreted language (most recent version in the raspbian repo)
  • nmap, a very popular port scanner, useful in our case for the bulk of the enumeration work
  • gobuster, a command-line tool for doing content discovery against webapps and websites
  • sqlite3, a popular implementation of Standard Query Language database technology
  • Tapestry, a Kensho Security Labs project, for doing data packaging and encryption

Tapestry is almost certainly overkill-for-purpose, but re-using it saves me the trouble of having to build out a solution to do nearly the same thing.

In addition to these programs, we'll also have to do a whole host of configuration tweaks and grabbing wordlists to drive dirb's queries.

Custom Scripts and Special Configuration

In addition to preconfiguring the EnumPi's tools and presetting its network conditions, we'll need a script, or scripts for the following:

  • Initial Startup: Data Curation and Estabilishing the VPN
  • Host Enumeration: Using nmap to build a database of available hosts
  • Deep Port Scanning: Using nmap to query the available hosts and find as much about ports and running services as possible.
  • Dirbusting: Using dirb to enumerate content on hosts with ports 80/433 open.

Finally, I'll spin up a small suite of scripts to help parse all this data when I have it back, to package the data on the RPi for transfer, and to automate the request process between the raspberry pi and my Kali instance (or indeed, any other host I wish to use).

That's it for this section of the guide - we now have enough to proceed. It's important to note that each of the project components can be broken down into smaller and smaller components. This is good - that means we can keep just cutting everything down into more and more managable work. In this case, that's left as an exercise to the reader (and the writer - I do have to get this work done, after all!)

While you're waiting for more information about the EnumPi, or indeed, if you want to check out our other projects, I'd encourage you to check out our actual projects page using the links above. Additionally, if you're interested in a similar project and you'd like our input, check out the services tab. If you liked this guide, and want to see more like it, please share with your friends or consider donating to our Coffee Fund!