P4wnP1_aloa

P4wnP1 A.L.O.A.

P4wnP1 A.L.O.A. by MaMe82 is a framework which turns a Rapsberry Pi Zero W into a flexible, low-cost platform for pentesting, red teaming and physical engagements ... or into "A Little Offensive Appliance".

0. How to install

The latest image could be found under release tab.

The easiest way to access a fresh P4wnP1 A.L.O.A. installation is to use the web client via the spawned WiFi (the PSK is MaMe82-P4wnP1, the URL http://172.24.0.1:8000) or SSH (default password toor).

1. Features

Plug&Play USB device emulation

• USB functions:
  • USB Ethernet (RNDIS and CDC ECM)
  • USB Serial
  • USB Mass Storage (Flashdrive or CD-Rom)
  • HID Keyboard
  • HID Mouse
• runtime reconfiguration of USB stack (no reboot)
• detection of connect/disconnect makes it possible to keep P4wnP1 A.L.O.A powered up (external supply) and trigger action if the emulated USB device is attached to a new host
• no need to deal with different internal ethernet interfaces, as CDC ECM and RNDIS are connected to a virtual bridge
• persistent store and load of configuration templates for USB settings

HIDScript

• replacement for limited DuckyScript
• sophisticated scripting language to automate keyboard and mouse
• up to 8 HIDScript jobs could run in parallel (keep a job up to jiggle the mouse, while others are started on-demand to do arbitrary mouse and keystroke injection seamlessly)
• HIDScript is based on JavaScript, with common libraries available, which allows more complex scripts (function calls, using Math for mouse calculations etc.)
• keyboard
  • based on UTF-8, so there's no limitation to ASCII characters
  • could react on feedback from the hosts real keyboard by reading back LED state changes of NUMLOCK, CAPSLOCK and SCROLLLOCK (if the target OS shares LED state across all connected keyboards, which isn't the case for OSX)
  • take branching decisions in HIDScript, based on LED feedback
• mouse
  • relative movement (fast, but not precise)
  • stepped relative movement (slower, but accurate ... moves mouse in 1 DPI steps)
  • absolute positioning on Windows (pixel perfect if target's screen dimensions are known)
• Keyboard and mouse are not only controlled by the same scripting language, both could be used in the same script. This allows combining them in order to achieve goals, which couldn't be achieved using only keyboard or mouse.
• current language layouts: br, de, es, fr, gb, it, ru and us

Bluetooth

• full interface to Bluez stack (currently no support for remote device discovery/connect)
• allows to run a Bluetooth Network Access Point (NAP)
• customizable Pairing (PIN based legacy mode or SSP)
• High Speed support (uses 802.11 frames to achieve WiFi like transfer rates)
• Runtime reconfiguration of the Bluetooth stack
• Note: PANU is possible, too, but currently not supported (no remote device connection)
• persistent store and load of configuration templates for Bluetooth settings

WiFi

• modified Firmware (build with Nexmon framework)
  • allows KARMA (spoof valid answers for Access Points probed by remote devices and allow association)
  • broadcast additional Beacons, to emulate multiple SSIDs
  • WiFi covert channel
  • Note: Nexmon legacy monitor mode is included, but not supported by P4wnP1. Monitor mode is still buggy and likely to crash the firmware if the configuration changes.
• easy Access Point configuration
• easy Station mode configuration (connect to existing AP)
• failover mode (if it is not possible to connect to the target Access Point, bring up an own Access Point)
• runtime reconfiguration of WiFi stack
• persistent store and load of configuration templates for WiFi settings

Networking

• easy ethernet interface configuration for
  • bluetooth NAP interface
  • USB interface (if RNDIS/CDC ECM is enabled)
  • WiFi interface
• supports dedicated DHCP server per interface
• support for DHCP client mode
• manual configuration
• persistent store and load of configuration templates for each interface

Tooling

Not much to say here, P4wnP1 A.L.O.A. is backed by KALI Linux, so everything should be right at your hands (or could be installed using apt)

Configuration and Control via CLI, remotely if needed

• all features mentioned so far, can be configured using a CLI client
• the P4wnP1 core service is a single binary, running as systemd unit which preserves runtime state
• the CLI client interfaces with this service via RPC (gRPC to be specific) to change the state of the core
• as the CLI uses a RPC approach, it could be used for remote configuration, too
• if P4wnP1 is accessed via SSH, the CLI client is there, waiting for your commands (or your tab completion kung fu)
• the CLI is written in Go (as most of the code) and thus compiles for most major platforms and architectures

So if you want to use a a batch file running on a remote Windows host to configure P4wnP1 ... no problem:

1. compile the client for windows
2. make sure you could connect to P4wnP1 somehow (Bluetooth, WiFi, USB)
3. add the host parameter to your client commands
4. ... and use the CLI as you would do with local access.

Configuration and Control via web client

Although it wasn't planned initially, P4wnP1 A.L.O.A. can be configured using a webclient. Even though the client wasn't planned, it evolved to a nice piece of software. In fact it ended up as the main configuration tool for P4wnP1 A.L.O.A. The webclient has capabilities, which couldn't be accessed from the CLI (templates storage, creation of "TriggerActions").

The core features:

• should work on most major mobile and desktop browsers, with consistent look and feel (Quasar Framework)
• uses gRPC via websockets (no RESTful API, no XHR, nearly same approach as CLI)
• Thanks to this interface, the weblient does not rely on a request&reply scheme only, but receives "push events" from the P4wnP1 core. This means:
  • if you (or a script) changes the state of P4wnP1 A.L.O.A. these changes will be immediately reflected into the webclient
  • if you have multiple webclients running, changes of the core's state will be reflected from one client to all other clients
• includes a HIDScript editor, with
  • syntax highlighting
  • auto-complete (CTRL+SPACE)
  • persistent storage & load for HIDScripts
  • on-demand execution of HIDScript directly from the browser
  • a HIDScript job manager (cancel running jobs, inspect job state and results)
• includes an overview and editor for TriggerActions
• full templating support for all features described so far
• the WebClient is a Single Page Application, once loaded everything runs client side, only gRPC request are exchanged

Automation

The automation approach of the old P4wnP1 version (static bash scripts) couldn't be used anymore.

The automation approach of P4wnP1 A.L.O.A. had to fulfills these requirements:

• easy to use and understand
• usable from a webclient
• be generic and flexible, at the same time
• everything doable with the old "bash script" approach, should still be possible
• able to access all subsystems (USB, WiFi, Bluetooth, Ethernet Interfaces, HIDScript ... )
• modular, with reusable parts
• ability to support (simple) logical tasks without writing additional code
• allow physical computing, by utilizing of the GPIO ports

With introducing of the so called "TriggerActions" and by combining them with the templating system (persistent settings storage for all sub systems) all the requirements could be satisfied. Details on TriggerActions could be find in the WorkFlow section.

Usage tutorial

2. Workflow part 1 - HIDScript

P4wnP1 A.L.O.A. doesn't use concepts like static configuration or payloads. In fact it has no static workflow at all.

P4wnP1 A.L.O.A. is meant to be as flexible as possible, to allow using it in all possible scenarios (including the ones I couldn't think of while creating P4wnP1 A.L.O.A.).

But there are some basic concepts, I'd like to walk through in this section. As it is hard to explain everything without creating a proper (video) documentation, I visit some common use cases and examples in order to explain what needs to be explained.

Nevertheless, it is unlikely that I'll have the time to provide a full-fledged documentation. So I encourage everyone to support me with tutorials and ideas, which could be linked back into this README

Now let's start with one of the most basic tasks:

2.1 Run a keystroke injection against a host, which has P4wnP1 attached via USB

The minimum configuration requirement to achieve this goal is:

• The USB sub system is configured to emulate at least a keyboard
• There is a way to access P4wnP1 (remotely), in order to initiate the keystroke injection

The default configuration of P4wnP1's (unmodified image) meets these requirements already:

• the USB settings are initialized to provide keyboard, mouse and ethernet over USB (both, RNDIS and CDC ECM)
• P4wnP1 could already be accessed remotely, using one of the following methods:
  • WiFi
    • the Access Point name should be obvious
    • the password is MaMe82-P4wnP1
    • the IP of P4wnP1 is 172.24.0.1
  • USB Ethernet
    • the IP of P4wnP1 is 172.16.0.1
  • Bluetooth
    • device name P4wnP1
    • PIN 1337
    • the IP is 172.26.0.1
    • Note: Secure Simple Pairing is OFF in order to force PIN Pairing. This again means, high speed mode is turned off, too. So the bluetooth connection is very slow, which is less of a problem for SSH access, but requesting the webclient could take up to 10 minutes (in contrast to some seconds with high speed enabled).
• a SSH server is accessible from all the aforementioned IPs
• The SSH user for KALI Linux is root, the default password is toor
• The webclient could be reached over all three connections on port 8000 via HTTP

Note: Deploying a HTTPS connection is currently not in scope of the project. So please keep this in mind, if you handle sensitive data, like WiFi credentials, in the webclient. The whole project isn't built with security in mind (and it is unlikely that this will ever get a requirement). So please deploy appropriate measures (f.e. restricting access to webclient with iptables, if the Access Point is configured with Open Authentication; don't keep Bluetooth Discoverability and Connectability enabled without PIN protection etc. etc.)

At this point I assume:

1. You have attached P4wnP1 to some target host via USB (the innermost of the Raspberry's micro USB ports is the one to use)
2. The USB host runs an application, which is able to receive the keystrokes and has the current keyboard input focus (f.e. a text editor)
3. You are remotely connected to P4wnP1 via SSH (the best way is WiFi), preferably the SSH connection is running from a different host, then the the one which has P4wnP1 A.L.O.A. attached over USB

In order to run the CLI client from the SSH session, issue the following command:

…

The help screen already shows, that the CLI client uses different commands to interact with the various subsystems of P4wnP1 A.L.O.A. Most of these commands have own sub-commands, again. The help for each command or sub-command could be accessed by appending -h to the CLI command:

…

Now, in order to type out "Hello world" to the USB host, the following CLI command could be used:

P4wnP1_cli hid run -c 'type("Hello world")'

The result output in the SSH session should look similar to this:

TempFile created: /tmp/HIDscript295065725
Start appending to 'HIDscript295065725' in folder 'TMP'
Result:
null

On the USB host "Hello World" should have been typed to the application with keyboard focus.

If your SSH client runs on the USB host itself, the typed "Hello world" ends up somewhere between the resulting output of the CLI command (it doesn't belong to the output, but has been typed in between).

**Goal achieved. We injected key