Lux Æterna Posted October 23, 2017 Share Posted October 23, 2017 Hey @Sebkinne, any plans on making a PS wiki repo? I was meaning to write a chapter on how to seamlessly expose a LAN segment with OpenVPN. It's a feature I've been using for a long time with small OpenWRT devices (ZSUN sticks, WT3020F, MR3020 etc) and it's awesome for remote management access, as you can seamlessly access the target subnet without having to forward/proxy every single IP/port combination. Link to comment Share on other sites More sharing options...
Dave-ee Jones Posted October 23, 2017 Share Posted October 23, 2017 I believe this is in the works - though it sounds like there's going to be a single point of information for all devices, or something along those lines. Link to comment Share on other sites More sharing options...
Lux Æterna Posted October 23, 2017 Author Share Posted October 23, 2017 Thank you, it makes sense seeing the new layout. I didn't think my guide warranted a brand new payload, maybe a PR of the existing one? I'll see when I get my PS in the mail :) Link to comment Share on other sites More sharing options...
Darren Kitchen Posted October 24, 2017 Share Posted October 24, 2017 It's at https://github.com/hak5/packetsquirrel-wiki but currently not live. I'd love to hear how you tackled the seamlessly accessing the target subnet with the planted device "dialing out" Link to comment Share on other sites More sharing options...
Lux Æterna Posted October 24, 2017 Author Share Posted October 24, 2017 Hey Darren, although it's pretty simple I admit it took me some trial and error to get it working, but now that I did I can manage 5+ networks from home without an issue. It basically boils down to pushing routes to other VPN clients while specifying which client will actually be the router, and a little bit of iptables magic of course. A word of caution: since we're going to push routes to your computer and 90% of common subnets are either 192.168.0.0/24 or 192.168.1.0/24 I advise you change your home/most used network to something a bit more uncommon, like 192.168.57.0/24, as to avoid overlapping. I'm going to assume an OpenVPN server is already set up and running. So, let's say that my home network is 192.168.57.0/24 and I want to use a PS to manage target network 192.168.0.0/24. Let's also assume my VPN subnet is something like 10.9.20.0/24, and that your computer and PS when connected to the VPN have the IPs 10.9.20.4 and 10.9.20.8 respectively. On my VPN server I need to create a new folder to contain client specific directives. mkdir /etc/openvpn/ccd In this folder I'm going to create a file that's named exactly like the client name I used when I created a certificate for the PS (this is important, if you don't otherwise it's not going to work). I'm going to assume it was packetsquirrel vi /etc/openvpn/ccd/packetsquirrel In this file I'm going to insert this line iroute 192.168.0.0 255.255.255.0 This tells OpenVPN that the route 192.168.0.0/24 is going to flow through this specific client. Then you need to edit your openvpn's server.conf client-to-client # allows VPN clients to communicate with each other client-config-dir /etc/openvpn/ccd/ # specifies the folder we created earlier as client-config-dir push "route 192.168.0.0 255.255.255.0" # pushes the route 192.168.0.0/24 to every connected client route 192.168.0.0 255.255.255.0 # adds this route to the OpenVPN server itself Once you've done that restart your OpenVPN server. If everything went smoothly you should be able to SSH into the PS directly with "ssh root@10.9.20.8". Do that, and from inside the PS run this command: iptables -t nat -A POSTROUTING -o eth1 -s 10.9.20.0/24 -j MASQUERADE (Warning: I'm not sure this was the only needed IPTables rule, I'm going to check again once I get my hands on the PS, as my existing routers are a forest of rules :) ) Again if everything went smoothly you should be able to seamlessly reach every device on the target's LAN (eg: 192.168.0.1 for the router). And that's pretty much it. Sadly the last part is a bit fuzzy as it's been a while since I set it up, but I'm going to write an in-depth guide once I receive my PS. Hope this helped! Link to comment Share on other sites More sharing options...
taswanita Posted October 25, 2017 Share Posted October 25, 2017 very complete thanks mate Link to comment Share on other sites More sharing options...
Lux Æterna Posted October 25, 2017 Author Share Posted October 25, 2017 18 minutes ago, taswanita said: very complete thanks mate You're very welcome :) I'll make sure to update it asap. It's something I hold particularly dear because it helped me maintain access so many times before. It's also one of the reason I particularly like OpenWRT: extremely small devices are enough to backdoor an entire network. Link to comment Share on other sites More sharing options...
Darren Kitchen Posted October 25, 2017 Share Posted October 25, 2017 Wow - this is fantastic. I'll attempt to duplicate this with the Packet Squirrel ASAP. I've done similarly with the LAN Turtle on Hak5 using OpenVPN-AS and, I wouldn't say it was a nightmare, but it was nowhere near as straight forward as your write-up. Thank you! The only difficulty I see is that the OpenVPN server needs prior knowledge of the remote network's IP scheme -- in your example 192.168.0.0/24. In the event that one is dropping a Packet Squirrel on a network as part of a penetration test through means of social engineering, prior knowledge of the IP scheme may not be available. I wonder in that case if a script on the Packet Squirrel end could then enumerate the LAN before establishing the OpenVPN connection, and then pass over its own config to be used. Perhaps then "re-dialing" if need be. Link to comment Share on other sites More sharing options...
Lux Æterna Posted October 25, 2017 Author Share Posted October 25, 2017 1 minute ago, Darren Kitchen said: I wonder in that case if a script on the Packet Squirrel end could then enumerate the LAN before establishing the OpenVPN connection, and then pass over its own config to be used. Perhaps then "re-dialing" if need be. That's definitely something I considered doing in the past, but it really hasn't been a problem: as long as you have the client-to-client directive in your OpenVPN server and the network has DHCP you'll always be able to ssh in the PS, check the WAN subnet and course-correct. I own a flock of ZSUN sticks that I use exactly for this purpose, and customize them depending on the client/engagement: plug them somewhere, configure their client mode, take note of the subnet, edit the conf files accordingly and bam, free backdoor as long as the AP stays up. Link to comment Share on other sites More sharing options...
Darren Kitchen Posted October 25, 2017 Share Posted October 25, 2017 7 minutes ago, Lux Æterna said: That's definitely something I considered doing in the past, but it really hasn't been a problem: as long as you have the client-to-client directive in your OpenVPN server and the network has DHCP you'll always be able to ssh in the PS, check the WAN subnet and course-correct. Good call. In that case said auto-routing script could live on the VPN server side. As it turns out this same conundrum was sorted on a LAN Turtle thread regarding the OpenVPN-AS method I had previous stated Link to comment Share on other sites More sharing options...
Lux Æterna Posted October 25, 2017 Author Share Posted October 25, 2017 45 minutes ago, Darren Kitchen said: Wow - this is fantastic. I'll attempt to duplicate this with the Packet Squirrel ASAP. I've done similarly with the LAN Turtle on Hak5 using OpenVPN-AS and, I wouldn't say it was a nightmare, but it was nowhere near as straight forward as your write-up. Thank you! Also, funnily enough I remember that episode because I was looking for a more "streamlined" way to do exactly this. Sadly OpenVPN AS is too limited for my needs, and in the end the Unix just-read-the-man-page-and-do-it-from-the-cli way always wins in the long run. 20 minutes ago, Darren Kitchen said: Good call. In that case said auto-routing script could live on the VPN server side. As it turns out this same conundrum was sorted on a LAN Turtle thread regarding the OpenVPN-AS method I had previous stated Much better idea IMHO. I always try to keep my devices from calling too much home because I always assume they'll be discovered and I definitely don't want to give away information about my infrastructure in case of closer inspection; server -> client, however, it's preferable because it's much harder to detect, especially if you don't keep logs on the device. Link to comment Share on other sites More sharing options...
Lux Æterna Posted October 25, 2017 Author Share Posted October 25, 2017 5 hours ago, Darren Kitchen said: Good call. In that case said auto-routing script could live on the VPN server side. The only downside I could think of is that automating the process could lead to subnet overlapping on your client PC if you're not careful and double check every time. Say you need to plant the packet squirrel on a 192.168.0.0/24 and your home network is 192.168.57.0/24: unless you start the OpenVPN client only when you know you're on an "unconventional" subnet you're fine, but if you want to bring your laptop to, say, a Starbucks or a new network altogether you may find it shares a subnet (192.168.0.0/24) with the target network, and with your computer unable to connect properly to the internet. So yeah maybe a client-side discovery script with a big disclaimer on where to NOT launch VPN would be a good idea. A nice workaround (that I'm going to test immediately) is to push the OpenVPN routes with the highest possible metric: worst case scenario you can't access the remote subnet, but you'll still able to connect to the internet and the Packet Squirrel. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.