Jump to content

Lux Æterna

Active Members
  • Content Count

    15
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Lux Æterna

  1. Also Cloud C2 is great, but my idea was to try and make it a little bit more standalone, as connecting to an host is "noisier" on a network level, and also leaves a bigger footprint (ie: DNS logs, traffic to a specific port etc). But I understand completely, no worries. Thanks for getting back to me Darren!
  2. I purchased all three on day one 🙂 I actually wrote a guide last year on how to backdoor a subnet via OpenVPN on a PS on its subforum
  3. Hey there, I just got my SC and while playing around with it I thought about some possible additions to this great device: 1) RTSP streaming. I don't know the specs of the device so I'm not sure how feasible this is but it would be great to just point VLC at it and stream it in real time. 2) some way to remote into it, ie. OpenVPN + SSH. Again, I don't know the specs but if it was possible it could basically become a capture device AND a backdoor to a network! 3) email reporting! 4) wifi master mode, to broadcast an SSID to connect to and remotely access stuff on it. I'm sure you already thought of some of this stuff, just thought I'd throw my 2 cents in.
  4. If I understand correctly what you and @Yaricks are trying to accomplish, I made a post about it here It's something I've been using for quite a while to bridge a remote network and access it seamlessly. Hope this helps!
  5. Hi all, several months ago I wrote a guide on how to seamlessly connect OpenVPN clients to the PS' LAN (e.g. your laptop from your home connection connecting to a printer in the same LAN as the PS, without having to use SSH as a proxy), but due to OpenWRT's preconfigured firewall I missed some iptables configurations to make it work properly (thank you @m3t4lk3y for pointing this out). So I figured I'd write a new, corrected standalone post. This is useful to manage remote subnets from anywhere with more than one VPN client (as this OpenVPN AS feature is paywalled, also this is completely headless, no clunky web interface required) 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 echo "iroute 192.168.0.0 255.255.255.0" > /etc/openvpn/ccd/packetsquirrel 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 commands (assuming your WAN interface in the PS is br-lan, if not it should be eth1, depending on your PS' network configuration): # Packets flowing from 10.9.20.0/24 (tun0) to 192.168.0.0/24 (br-lan) should be accepted and forwarded iptables -I FORWARD -i tun0 -o br-lan -s 10.9.20.0/24 -d 192.168.0.0/24 -m conntrack --ctstate NEW -j ACCEPT # Masquerade packets coming from 10.9.20.0/24 as coming from the PS' WAN IP iptables -t nat -I POSTROUTING -o br-lan -s 10.9.20.0/24 -j MASQUERADE If everything went smoothly you should be able to seamlessly reach every device on the target's LAN (e.g. 192.168.0.1 for the router). Keep in mind that iptables rules are volatile, meaning they will be reset should the PS get rebooted. I could have put the configurations on the config files but seen the portable/multifunction nature of the device I'd rather run it by hand than possibly breaking the defaut network configurations intended by Hak5.
  6. Hey @Master Luc, if you don't need to route all the traffic at a lower level you could simply use SSH to create a quick and dirty SOCKS5 proxy. Say your PS'' OpenVPN IP is 10.20.30.3, from your laptop you could do something like: ssh -f -D 0.0.0.0:2222 root@10.20.30.3 -p 22 -N -q This simply creates background SSH connection (-f) binding local port 2222 (-D 0.0.0.0:2222) to user root at 10.20.30.3 port 22 (root@10.20.30.3 -p 22) without executing any other commands (-N) and without printing debug informations/errors (-q). In your Firefox configuration you can now use localhost port 2222 as a SOCKS5 proxy and route all traffic through your home connection. Note that by using 0.0.0.0 the proxy will listen on your every available interface, meaning you can use your laptop as a gateway for other devices in your LAN (a Smart TV, another laptop, etc...). If you don't need to do that however I advise you to use 127.0.0.1, as listening on every interface is a security risk.
  7. Hey, I just upgraded manually my LAN Turtle, so I had to start from scratch setting up my modules. One thing I noticed right away is that even if my LT connected to my OpenVPN server just fine I still couldn't connect to it via SSH. The simple fix was to append this line to the LAN zone in /etc/config/firewall option network 'lan vpn' If everything went smoothly your zone should look like this, with the new line being the 15th in the whole file: config zone option name lan list network 'lan' option input ACCEPT option output ACCEPT option forward ACCEPT option network 'lan vpn'
  8. Hey @StampeRnator, I detailed my solution to your problem here, hope this helps!
  9. 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.
  10. 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. 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.
  11. 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.
  12. 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.
  13. 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!
  14. 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 :)
  15. 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.
×
×
  • Create New...