Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Phantap on debian based systems #18

Open
hutchYy opened this issue Apr 22, 2024 · 8 comments
Open

Phantap on debian based systems #18

hutchYy opened this issue Apr 22, 2024 · 8 comments

Comments

@hutchYy
Copy link

hutchYy commented Apr 22, 2024

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
Copy link

darknetehf commented Apr 23, 2024

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
Copy link

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...
  1. Rebooting without warning is not desirable IMHO (we might have uncommited stuff)
  2. 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
Copy link
Author

hutchYy commented Jul 1, 2024

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
Copy link
Author

hutchYy commented Jul 1, 2024

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:
image

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

Best regards,
hutchyy

@darknetehf
Copy link

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
Copy link

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

@hutchYy
Copy link
Author

hutchYy commented Aug 4, 2024

Hey @darknetehf,

Thanks for your time :P

I've built it for Kali Linux readiness as I guess this is the simpliest way to have all the testing tools deployed.
OFC, you could still built your own debian based OS with your tools, but the goal here was to have an easily and rapidly deployable network tap.

Looking at the Nanopi R1 it seems that there are no out of the box images for Kali.
However Kali has a list of "supported" devices including the nano pi 2

Here you also have the list of already supported devices for running Rockchip SoCs:
https://http.kali.org/dists/kali-rolling/main/installer-arm64/current/images/device-tree/rockchip/

I see that this list include the nanopi r4s which sounds like a good option 😊

Regarding the MAC stealth spoofing, please share more details so we can look together at this.
For OpenWRT it was a kernel option to disable so maybe with Debian kernel it is a different option.

I've enabled issues on the forked repo, so knock yourself out!

See you!

@darknetehf
Copy link

@hutchYy I just filed a detailed issue on your repo :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants