Phantap on debian based systems

[hutchYy]

Hi maintainers,

I have written a major rewrite of the Phantap OpenWRT implementation (not the binary) to make it compatible with Debian-based systems.

Long story short: I needed a use case for a Zimma Board (Zimma Board Shop), which uses an x86 platform and boasts considerable performance. It also includes an embedded TPM that allows the device to be fully locked, thereby preventing potential attackers from replacing or tampering with the firmware. Consequently, I chose to run Debian because it supports secure boot and disk encryption using TPM, which I believe is safer for a field implant (Red Teaming).

I forked the project(forked repo here) and it is now operational on my repository, but I think it would be beneficial to integrate these changes here. Currently, there is an installation script that installs all necessary files and required components, including an uninstallation script.

To further refine this, I am considering releasing simple .deb packages for at least MIPS, ARM, and Intel architectures.

Note: At the moment, I have only tested this on my ZimmaBoard, but I plan to test it on my OrangePi 5B as well.

Please let me know if you are interested, so I can start a PR in a "Debian"? branch. 😊

Have a nice day!

Best regards, hutchyy

[darknetehf]

This could be a promising development. We have used Armbian on some SBCs in the past, so I'm assuming this package would be compatible with that platform. OpenWRT is neat, but the tools at our disposal are drastically limited. For example, running a remote Xorg session on the box is not really feasible with OpenWRT.

In a nutshell, all that is needed is a regular Linux bridge, but the trick is to make the box as silent as possible, and masquerade any frames originating from the pwnbox, so that they appear to be coming from the victim. In practical terms: solid firewall rules, disabling chatter from certain services like ARP or multicast, which I see you did.

I could try this on a NanoPi R1 with Armbian, time permitting. I use SPAN (port mirroring) on the switch to verify the MAC address of the box is not leaking.

By the way, it's been a while, but I think Armbian actually runs NetworkManager by default.

[darknetehf]

Hello @hutchYy

Today I have attempted to make your script run on Armbian (on a Friendly Elec Nanopi device). I have noticed some potential issues:

1. When running install.sh, there is an error involving phantap-uninstall.sh (chmod + cp), see the trace below. It is probably because of: cd $BUILD_DIR (we are in subdir src) Although I don't think this would matter a lot.

bridge-utils is already the newest version (1.7.1-1).
dnsmasq is already the newest version (2.89-1).
0 upgraded, 0 newly installed, 0 to remove and 7 not upgraded.
Synchronizing state of dnsmasq.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable dnsmasq
Copying startup files to init
Copying udev rules to udev
Copying iptables rules
Copying dnsmasq.d rules
Copying networking
Compilation and installation of phantap-learn completed.
-- CMAKE_BUILD_TYPE is not set, set to default = RelWithDebInfo
-- CMAKE_BUILD_TYPE: RelWithDebInfo
-- Configuring done
-- Generating done
-- Build files have been written to: /root/phantapv2/src
[100%] Built target phantap-learn
Moving compiled executable to /usr/sbin/phantap-learn
Performing the setup of phantap
Adding uninstall script to /usr/sbin/phantap-uninstall
chmod: cannot access 'phantap-uninstall.sh': No such file or directory
cp: cannot stat './phantap-uninstall.sh': No such file or directory
Setup is done, rebooting now...

2. Rebooting without warning is not desirable IMHO (we might have uncommited stuff)
3. The service phantap does not seen to be running on reboot. Output of systemctl status phantap.service:

   × phantap.service - LSB: PhanTap init script
    Loaded: loaded (/etc/init.d/phantap; generated)
    Active: failed (Result: exit-code) since Sun 2024-05-05 21:55:39 UTC; 3s ago
      Docs: man:systemd-sysv-generator(8)
   Process: 1604 ExecStart=/etc/init.d/phantap start (code=exited, status=2)
       CPU: 54ms

May 05 21:55:39 nanopi-r1 systemd[1]: Starting phantap.service - LSB: PhanTap init script... May 05 21:55:39 nanopi-r1 phantap[1604]: /etc/init.d/phantap: 93: Syntax error: "(" unexpected May 05 21:55:39 nanopi-r1 systemd[1]: phantap.service: Control process exited, code=exited, status=2/INVALIDARGUMENT May 05 21:55:39 nanopi-r1 systemd[1]: phantap.service: Failed with result 'exit-code'. May 05 21:55:39 nanopi-r1 systemd[1]: Failed to start phantap.service - LSB: PhanTap init script. Note this line:

/etc/init.d/phantap: 93: Syntax error: "(" unexpected

There appears to be a syntax error in the init script.

Are you sure that the scripts are OK or maybe it's my config? dnsmasq looks broken on my end but I don't think that's the reason.

[hutchYy]

Hey @darknetehf

Thanks for the feedback!

I will have a look this week at:

• Adding a Y/N for reboot.
• Fix the phantap-uninstall
• Reproduce your issues on Armbian to see what needs to be patched.

Maybe, can you attach the phantap script line 93 to see what's the issue?

Have a nice one!

[hutchYy]

Hey @darknetehf

I had the time to have a look at the scripts.

I've added the Y/N for reboot Fixed the phantap-uninstall Fixed the phantap service so it uses bash instead of sh.

Based on that I performed a retest on a fresh Debian and it seems to work:

Let me know if you face any other issues 😮‍💨

Best regards, hutchyy

[darknetehf]

Many thanks for that. Here is some quick feedback after testing the app on a Nanopi R1.

I wanted to test with Armbian and tried the Debian & Ubuntu versions but they are not adequate as they ship with Network Manager or netplan, systemd-resolved which conflicts with dnsmasq, /etc/network/interfaces missing etc. Definitely not the best way to test.

So I eventually used the Debian-based version (FriendlyCore) supplied by Friendlyelec (h3-sd-debian-bookworm-core-4.14-armhf-20231213.img). I disabled NetworkManager service to avoid interference.

The app seems to work OK. It does the job as a transparent bridge, but I noticed that the bridge itself leaks its own MAC address in DNS queries. We definitely want to avoid MAC address leaks to escape detection. I will be filing a more detailed issue in your repo later.

Given that Openwrt has a different architecture, this version is shipping with some files not relevant to Debian/systemd like the init.d files and it should probably coexist as a distinct Debian branch.

[darknetehf]

@hutchYy I think you need to enable issues in your repo ;)