hachiman

Hi there, I am currently trying to get my OpenVPN demo up and running, making it possible to remotely connect to the network the turtle is connected to. Baseline is the setup as described by Darren: Access Internal Networks with Reverse VPN connections - Hak5 1921 I have my OpenVPN server, I have created a user for the turtle, one for the laptop, all good. Both can connect to the OpenVPN and I can even connect back to the turtle and SSH in to it. But I am not able to go any further from that into the internal network the connected to the RJ45 port at the turtle. When I use the OpenVPN to ssh into the turtle, I can ping the resource in question. Apparently I make some mistakes with the routing config on the OpenVPN? Sorry but I cant upload images anymore, so I have to describe what I did. The OpenVPN turtle user is configured as VPN Gateway, with the following subnets 172.16.0.0/16 & 192.168.0.0/16. This is the turtle output: root@turtle:~# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 172.27.224.1 128.0.0.0 UG 0 0 0 tun0 default 172.16.7.254 0.0.0.0 UG 20 0 0 eth1 default 172.16.84.84 0.0.0.0 UG 30 0 0 eth0 128.0.0.0 172.27.224.1 128.0.0.0 UG 0 0 0 tun0 167.99.128.12 172.16.7.254 255.255.255.255 UGH 0 0 0 eth1 172.16.0.0 * 255.255.0.0 U 20 0 0 eth1 172.16.84.0 * 255.255.255.0 U 30 0 0 eth0 172.27.224.0 * 255.255.248.0 U 0 0 0 tun0 root@turtle:~# ifconfig eth0 Link encap:Ethernet HWaddr 00:13:37:A6:xx:xx inet addr:172.16.84.1 Bcast:172.16.84.255 Mask:255.255.255.0 inet6 addr: fe80::213:37ff:xxxx:xxxx/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:16 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:1960 (1.9 KiB) Interrupt:4 eth1 Link encap:Ethernet HWaddr 00:13:37:A6:xx:xx inet addr:172.16.15.161 Bcast:172.16.255.255 Mask:255.255.0.0 inet6 addr: fe80::213:37ff:::/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:118553 errors:0 dropped:1583 overruns:0 frame:0 TX packets:4310 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:12094247 (11.5 MiB) TX bytes:566197 (552.9 KiB) Interrupt:5 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:2488 errors:0 dropped:0 overruns:0 frame:0 TX packets:2488 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:168094 (164.1 KiB) TX bytes:168094 (164.1 KiB) tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:172.27.224.11 P-t-P:172.27.224.11 Mask:255.255.248.0 inet6 addr: fe80::e208:91c9:::/64 Scope:Link UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:346 errors:0 dropped:0 overruns:0 frame:0 TX packets:531 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:26292 (25.6 KiB) TX bytes:118753 (115.9 KiB) This is the client output └──╼ $ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.0.2.15 netmask 255.255.255.0 broadcast 10.0.2.255 inet6 fe80::67ce:549b::: prefixlen 64 scopeid 0x20<link> ether 08:00:27:b3:d8:99 txqueuelen 1000 (Ethernet) RX packets 9360 bytes 9749835 (9.2 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 6679 bytes 801398 (782.6 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 700 bytes 52508 (51.2 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 700 bytes 52508 (51.2 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500 inet 172.27.232.11 netmask 255.255.248.0 destination 172.27.232.11 inet6 fe80::3ade:e4c:: prefixlen 64 scopeid 0x20<link> unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC) RX packets 693 bytes 313538 (306.1 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 811 bytes 80166 (78.2 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ┌─[hackerman@parrot]─[~/Downloads] └──╼ $route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 172.27.232.1 128.0.0.0 UG 0 0 0 tun0 default 10.0.2.2 0.0.0.0 UG 100 0 0 eth0 10.0.2.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0 128.0.0.0 172.27.232.1 128.0.0.0 UG 0 0 0 tun0 167.99.128.12 10.0.2.2 255.255.255.255 UGH 0 0 0 eth0 172.27.232.0 0.0.0.0 255.255.248.0 U 0 0 0 tun0 When I establish the VPN connection on the client, I dont see any route adds for the specific network of 172.16.0.0/16, as I configured it in the OpenVPN GUI. 2021-08-30 11:26:00 ROUTE_GATEWAY 10.0.2.2/255.255.255.0 IFACE=eth0 HWADDR=08:00:27:b3:d8:99 2021-08-30 11:26:00 TUN/TAP device tun0 opened 2021-08-30 11:26:00 net_iface_mtu_set: mtu 1500 for tun0 2021-08-30 11:26:00 net_iface_up: set tun0 up 2021-08-30 11:26:00 net_addr_v4_add: 172.27.232.13/21 dev tun0 2021-08-30 11:26:05 ROUTE remote_host is NOT LOCAL 2021-08-30 11:26:05 net_route_v4_add: 1.199.128.12/32 via 10.0.2.2 dev [NULL] table 0 metric -1 2021-08-30 11:26:05 net_route_v4_add: 0.0.0.0/1 via 172.27.232.1 dev [NULL] table 0 metric -1 2021-08-30 11:26:05 net_route_v4_add: 128.0.0.0/1 via 172.27.232.1 dev [NULL] table 0 metric -1 2021-08-30 11:26:05 Initialization Sequence Completed Anyone any idea why? What am I missing in terms of routing?

Good idea. Just to be more specific on this case. I dont require long battery runtime. It is more a "proof of concept". Plug it in, get remote access to demo the vulnerability and then unplug it again. I dont have Packet Squirrel, but I have a LAN Turtle. Which I think also provides C2 integration and OpenVPN, right? So I could use the RJ45 to plug it into our network and use a normal power bank to keep it up and running while doing the demo. Do you think this would make sense? PS: A public server with c2 installed and running is available also.

Hey there, brief question for your help (my brain seems a bit lost here). I conducted an audit of our enterprise network and discovered sensitive websites. Second step would be to deploy a SJ and somehow be able to remotely connect to it, using it as a bridgehead, and then access some of these websites. Could this be done with some ssh -r remote forwarding config? I used this to access local webservers where the ssh is running, but would this work to connect like this: Browser on internet server -> Internet -> SharkJack -> Website? This is more like a demo case for our conference, so OPSEC is not a big matter here. Thanks everyone!

Hey everyone, just a brief update from my end. Maybe someone else comes across this and my experience can be of any help. After multiple strange failures with Kali Linux (lsusb works, lsmod etc. as well, but no traffic, no ARP, no DHCP, no HTTP on the eth int of MK7, except when MK7 is in recovery mode, USB filter set in VirtualBox): I tried it with a Win10 (also virt. guest on the same MBP on the same VirtualBox hypervisor) and all of a sudden it worked. Now I tried it with a fresh install of Parrot Sec and it works like a charm. I have no idea what this could be but it really bugs me out. So if you have a similar issue setting up WiFi Pineapple MKVII on Kali Linux, try a different OS.

Thanks for your feedback. I already have it and I was struggling with similar driver issues when using it with bettercap-ng etc. So it seems this is not really a smart choice. I will probably buy another adapter to enable 5Ghz on the MK7, as recommended by the Hak5 team. But thanks for the new driver link. I wasnt aware of that and still used the aircrack one.

Appreciate it @chrizree I think I have to open a ticket, or maybe @Darren Kitchenswings by this thread and has some other ideas.

I just tried it again. I put the MK7 into recovery mode, it works. I can access its website at 172.16.42.1 flawlessly. Now I am resetting it again, without much hope. After several tests I can say that the MK7 is easily accessible when in recovery mode. Normal startup and the website at 172.16.42.1 doesnt work, with no traffic at L2 or L3 be seen within Wireshark. NIC setup stays the same and is not altered. I kept ping running while accessing the recovery website, works perfectly fine. I can watch ARP resolution, ICMP packets and HTTP packets via wireshark. MK7 recovers and reboots in normal mode (with blue LED), ping dies, timeout, no ARP, only outgoing traffic in wireshark, nothing incoming anymore. PS: If I use my iPad in parallel to connect to the WiFi of the MK7 -> this works. So it is not the MK7 in general. There must be something wrong on the USB-C ethernet end. Even though I have no idea what that might be. EDIT: I would upload another screenshot, but apparently I used all my space here.

I am using the automatic filter. However I dont see the problem there. As mentioned above, when I set the MK7 into recovery mode, it miraculously works. Recap: Set MK7 into recovery mode and follow instructions at https://docs.hak5.org/hc/en-us/articles/360055166053-Firmware-Recovery Assign fixed IP settings for eth1 (which is the ASIX chipset) NIC, 172.16.42.42 with /24 subnet mask Open browser and go to 172.16.42.1 Result: It works and I can access the FW recovery website of the MK7 Analysis: The USB filter works, the ASIX chipset is correctly recognised by the Linux guest VM The driver in the Linux guest works, the NIC comes up, I can assign IP settings, I can ping the NIC at the assigned IP of 172.16.42.42 This implies also that the USB passthrough at hypervisor level works The USB-C port works at the MBP The USB-C cable works The ASIX chipset works Problem: After recovery and reboot of the MK7, the same problem occurs as before. Even when I skip DHCP and keep the existing settings for the eth1 NIC, I dont get any answer from the MK7 itself. Wireshark shows nothing on eth1, except outgoing arp requests for 172.16.42.1 If I revert back to DHCP for eth1, it is stuck sending DHCP requests but never receives an answer. Also seen in Wireshark.

Thanks @Jtyle6. I edited my post above. Super strange. The HTTP connection works when I put the MK7 in FW reset mode. After a successful reset and reboot (I assume based on the steady blue led light), it fails again. No reply on the eth1 NIC in my Linux box. So currently everything I try is inside a virtualized Linux machine, not on the MBP directly. However the error is quite similar. There is no IP traffic, no DHCP, no matter whether I use my MBP (with the possibility of a flawed ASIX driver on Big Sur with 2019 MBP), or when I use the Linux machine.

Thanks for the input. Doesnt work, even though I did everything as you did. USB filter for the Linux VM, disable all other NICs on the Linux VM, boot, ASIX gets recognized as eth1 (which is somewhat different from your description of enx001337xxxxxx, but that shouldnt matter). When I run Wireshark on the eth1 ASIX NIC I can see DHCP request but never any answers. When I configure it with a fixed IP of 172.16.42.42 and try to connect to 172.16.1.1 of the MK7, I see the correct route being setup and I see the corresponding ARP requests via Wireshark on eth1. But also, no reply. EDIT: So apparently this is something with the MK7 (kinda glad I am not that stupid). I went into recovery mode to see if it changes. I have eth1 manually configured for 172.16.42.42 etc. and eth0 as my standard uplink for the virtual NAT network. Now when I open the browser and go to http://172.16.42.1 it immediately works and I am able to select the recovery firmware. Thats strange. EDIT 2: After FW recovery connect to 172.16.42.1:1471 or :80 fails again.... that is utterly frustrating.

Hey everyone, as mentioned ASIX driver is not working on MacOS. I switched over to a (VirtualBox) Kali Linux guest. I have configured a USB filter to passthrough the ASIX NIC to the Linux machine, which works flawlessly. NIC with DHCP First I setup eth1 with DHCP. nmcli shows that it is trying to receive an IP address, however it fails. Wireshark on eth1 also shows DHCP requests, yet no replies. NIC with fixed settings Next I manually configured the IP settings. eth1 has been configured manually with 172.16.42.42, route seems to be all right. I further removed the main NIC (virtually unplugged the cable) to make sure there are no other interferences. Still no access. What I see is an error message asix_rx_fixup() bad header length in dmesg. Has anyone experience something similiar? Thanks!

Currently I am connecting the MK7 via USB-C ethernet to a linux box. As it was working yesterday I am now struggling with DHCP. The device is recognized, via lsusb, ifconfig, ip link, etc., but it wont get a DHCP assignment from the MK7. This also doesnt work when I explicitly configure it via nmclient or via Debian Network Manager GUI. So I first have to figure out what is wrong on that end. Yesterday ICS was working via wp7.sh script. PS: Thanks for the hint on the PSK chars and the upcoming firmware. Edit: Linux is really getting me crazy. I enabled NetworkManager to manage my NICs. First when I plug in the MK7 via USB-C, I see the "getting IP configuration" output for eth1. After a few seconds it changes to "unavailable". further investigating this.

@chrizreebrief question. I connected the MK VII with a linux box, yet DHCP doesnt work out of the box. Just when I manually added it to /etc/network/interfaces I got the corresponding IP address. However it messes up my routes and I lose internet access (because the MK7.lan announces an automatic route metric 0). Do you know whether this is the expected behaviour? PS: I need a workaround anyway. Accessing my WiFi to get the OTA download for the MK VII fails because it only accepts 32 chars passwords.

Thanks for that. Read about the 8812 issues. So lets see if it works. Otherwise going for the MT7612U.

Hi everyone, just wondering if anyone of you uses the Alfa AC1900 adapter on your MK VII? It has an RTL8814U chipset and works on the Kali Box, with the https://github.com/aircrack-ng/rtl8814au driver. Thought I can simply add the driver manually to the WP, would that work? Thanks!