Project Pentester in a Box
Posted by Peter Bassill on 21/07/2017Pentester in a Box
It may seem unusually cruel to put a pentester in a box, but this is my little project write up, from a project in 2017 that has been continuously engineering and evolved. It could equally be "how to build a pen-testing dropbox" or "how Hedgehog overcame COVID restrictions before they happened". But this is the storey of the PiaB (Pentester in a Box) project.
I had a need to give my clients a special, extra comfortable way to have their pentests performed. All too often clients would be unhappy about paying for the travel and accommodation costs for testers even when we kept them at an exceptionally low rate. Clients were increasing concerned about the lack of desk space they had available and it was starting to impede on testing windows. Something needed to change, and I thought I had the solution. Surely we could just ship a client an appliance.
Building a pentesting appliance is easy. Install Kali on something and send to a client. But wait a moment, lets do it properly. I was not going to do a slapdash job here. So in 2017 our devices are a very cheap intel system from China that failed more often that it started. These were very quickly replaced with Rasberry Pi units and then in 2020 we moved everything over to Intel NUC's.
Our current generation of appliance run with either 16GB or 32GB of memory and solid state 512GB storage for the OS and working files. For exceptionally large and long engagements, we ship a version with 1.5TB of storage.
All of our PiaB's, when powered on with wait for up to 20 minutes while they try to figure out how to connect to the internet. Once an internet connection is available, they will attempt to start a TLSv1.3 VPN on port TCP:443 back to our network. Communication is uni-directional. It only ever flows from the PiaB to us.
Where TCP:443 is not available, TCP:80 is tried as is TCP:22. Should all of those fail, TCP and UDP port 53 is used and should that fail, each NUC is fitted with a GPRS card to allow it to use the cellular networks as a backup communication path should it not be able to talk across the internet.
Secure on Boot
Each NUC boots into a mode where no, zero, services are running. If you were to portscan it, you should see nothing. In fact, in standard mode UFW on the devices runs as deny/deny so everything is blocked. When the PiaB starts a VPN connection, it will call its home ID page and retrieve its setttings. At this point, on a standard engagement, it will open port 22 on the VPN interface to allow the pentester to connect.
A word of Passwords
None of our PiaB applications have a known password. There is only one account on a freshly booted application. Root. Every 10 minutes there is a system process that will change the root password is a random 64 character string. This is what the script looks like:
RPASSWD=`openssl rand -base64 32` && echo "root:$RPASSWD"|chpasswd > /dev/null 2>&1
The pentesters user account is set up when the appliance pulls down its configuration from our network and the testers ssh keys are applied. No passwords exist anywhere.
But I can touch it
That is fine. You can touch it. In fact, I encourage clients to. If something is going wrong on the network and there is a pentest running, I always tell our clients to go and unplug the network interface on the application. Did the issue go away?
But yes, there is a level of trust. A client could open it up, pull the storage and try to read it. But the storage is AES256 encrypted. You could hook a monitor up to it, but the X interface is disabled and all you will see is a terminal login screen. As there are no passwords, no login will every be successful.