Bypassing Firewalls and Avoiding Detection
The
type and scope of the penetration test will determine the need for being
stealthy during a penetration test. The reasons to avoid detection
while testing are varied; one of the benefits would include testing the
equipment that is supposedly protecting the network, another could be
that your client would like to know just how long it would take the
Information Technology team to respond to a targeted attack on the
environment.
Not only will you need to be wary of
the administrators and other observers on the target network, you will
also need to understand the automated methods of detection such as web
application, network, and host-based intrusion detection systems that
are in place to avoid triggering alerts.
NOTE:-When
presented with the most opportune target, take the time to validate
that it is not some sort of honeypot that has been set up to trigger
alerts when abnormal traffic or activity is detected! No
sense in walking into a trap set by a clever administrator. Note that if you do find a system like this it is still very important to ensure it is set up properly and not inadvertently allowing access to critical
internal assets due to a configuration error!
sense in walking into a trap set by a clever administrator. Note that if you do find a system like this it is still very important to ensure it is set up properly and not inadvertently allowing access to critical
internal assets due to a configuration error!
Lab preparation:-
BackTrack, pfSense, and Metasploitable virtual machines should be configured in the following manner:
Kali Linux guest machine:-
This machine will need to be
connected to the 192.168.10.0/24 subnet. In the Oracle VM VirtualBox
Manager console highlight the Kali Linux instance and select the Settings option from the top navigation bar. Ensure that only one network adapter is enabled. The adapter should use the Vlan1 internal network option.
Now power on your Kali machine and configure IP address manually as follow:#ifconfig eth0 192.168.10.10 netmask 255.255.255.0
As the pfSense machine will need to be our router as well, we need to set it up as the default gateway. This can be accomplished as follows:
# route add default gw 192.168.10.1
Metasploitable guest machine:-
The Metasploitable machine will be used as the target. It needs to be configured to connect to VLAN2, which is a new internal network we have not used before.To create an internal network you will need to manually type VLAN2 into the network configuration screen in the Oracle VM VirtualBox Manager. Your settings should be similar to the following:pfSense network setup:-
Configuring our firewall is a bit more work. It needs to be able to route restrictive traffic from the VLAN1 network to the VLAN2 subnet. There are several configuration changes we will need to make to ensure this works properly.Our firewall guest machine will use two network adapters. One will be used for the VLAN1 segment and the other for the VLAN2 segment. VLAN1 will be treated as an untrusted wide area network for the examples within this chapter. Network Adapter 1 should resemble the following screenshot:
Network Adapter 2 should be similar to the following:
Pfsense WAN IP configuration:-
The remaining networking setup will need to be performed from within the guest machine.1. Boot up your pfSense virtual instance. There may be an additional delay as pfSense attempts to configure the WAN adapter. Allow it to fully load until you see the following menu:
2. The WAN and LAN interfaces will need to be configured properly.Select option 2) Set interface(s) IP address.
3. Select option 1 – WAN.
4. When asked to configure the WAN interface via DHCP type n for no.
5. The IP for the WAN adapter should be 192.168.10.1.
6. Subnet bit count should be set to 24. Type 24 and press Enter.
7. Next is set default gateway in our case 192.168.10.1.
8.Next will ask about IPv6 in our type n and press enter.
9. Finally you got bellow screen:
10. Press Enter again to return to the configuration menu.
Your LAN and WAN IP ranges should match the following:
Pfsense LAN IP configuration:-
We can set up the LAN IP information from the configuration menu as well. One benefit of configuring the LAN here is that we can have a DHCP server configured for VLAN2 at the same time.1. Select option 2 from the configuration menu to start the LAN IP Configuration module.
2. Choose the LAN interface (Option 2).
3. When prompted to enter the IP address type 192.168.20.1.
4. The bit count should be set to 24.
5. Next is set default gateway in our case 192.168.20.1.
6. When asked if you would like a DHCP server to be enabled on LAN choose y for yes.
7. DHCP Client IP range start will be 192.168.20.10.
8. DHCP Client IP range stop will be 192.168.20.50.
9. Press Enter again to return to the configuration menu.Your LAN and WAN IP ranges should match the following:
Firewall configuration:-
pfSense can be configured using its intuitive web interface. Boot up the Kali Linux machine with VLAN2, open a terminal and perform a sudo dhclient to pick up an address from the pfSense DHCP server on VLAN2 (192.168.20.0/24).In a web browser on the Ubuntu machine type http://192.168.20.1/ to access the configuration panel. If you have reset to factory defaults you will need to step through the wizard to get to the standard console.
Note:-The default username and password combination for pfSense is: admin/pfsense.
To view the current firewall rules choose Firewall | Rules and review the current configuration. By default the WAN interface should be blocked from connecting internally as there are not preestablished rules that allow any traffic through.
For testing purpose, we will enable ports 80, 443, 21, and allow ICMP. Add the rules as follows:
1. Click on the add a new rule button displayed in the preceding screenshot.
2. Use the following rule settings to enable ICMP pass-through:
- Action: Pass
- Interface: WAN
- Protocol: ICMP
- All others: Defaults
4. Click on the Apply Changes button at the top of the screen.
5. Use the Interface | WAN navigation menu to enter the WAN interface configuration menu and uncheck Block private networks. Apply the changes and return to Firewall | Rules.
6. Click on the add new rule button.
7. Use the following rule settings to enable HTTP pass-through.
- Action: Pass
- Interface: WAN
- Protocol: TCP
- Destination port range: HTTP
At this point any machine connected to VLAN1 can communicate through the open ports as well as ping machines on the VLAN2 segment as can be seen in the following screenshot
Finding out if the firewall is blocking certain ports:-
There is a firewall; now what? The next step is to determine which ports are being blocked by the firewall, or more importantly which are open.Hping:-
Hping2 and Hping3 are included as part of the Kali Linux distribution. It can be accessed via the GUI navigation bar Applications | Kali Linux | Information Gathering | Live Host Identify Live Hosts | Hping3. It can also be invoked at the command line by simply typing: hping2. Hping2 is a powerful tool that can be used for various security testing tasks. The following syntax can be used to find open ports while remaining fully in control of your scan:# hping3 -S 192.168.20.11 -c 80 -p ++1
This command allowed us to perform a SYN scan starting at port 1 and incrementing for 80 steps.
Depending on the firewall configuration it may also be possible to send spoofed packets. During a test it is beneficial to ensure that the configuration does not allow for this behavior to occur. Hping is perfectly suited for this task. The following is an example of how you may test if the firewall allows this traffic to pass:
#hping3 -c 10 -S --spoof 192.168.20.11 -p 80 192.168.20.100
This command will spoof 10 packets from 192.168.20.11 to port 80 on 192.168.20.100. This is the basis for an idle scan and if successful would allow you to hping the 192.168.20.11 machine to look for an increase in the IP sequence number. In this case we could enable monitoring on the pfSense machine to emulate what this traffic looks like to a network administrator reviewing the logs.
Challenge yourself to create and monitor different packets and uses of Hping so that you can gain a good understanding of the traffic flow. The best means of remaining undetected while testing is to fully understand the technology that is being used. Take a look at the logs generated from a successful scan and keep in mind that due to the amount of traffic involved even secured networks will sometimes only log and trigger events based on denied traffic.
Note:-Logging per rule will need to be enabled on the firewall to see allowed traffic. Not logging permitted traffic is fairly standard practice as it reduces the firewall log size. Educate your clients that proactively monitoring allowed traffic can also be beneficial when attempting to truly secure a network.
Nmap firewalk script:-
One of the easiest methods to test open ports on a firewall is to simply use the firewalking script for Nmap. To test the open firewall ports you will need a host behind the firewall as the target:#nmap --script=firewalk --traceroute 192.168.20.11
The command sequence is straightforward and familiar: we invoke nmap, use the script option, and choose the firewalk script. We then provide the input that firewalk needs by performing a traceroute to 192.168.20.11 which we know is behind our target firewall.
Although we were able to determine which ports on the firewall were open (21, 80, and 443), if you take a look at the firewall denies it quickly becomes apparent that this is not a quiet test and should only be used when stealth is not needed. What this boils down to is that stealth requires patience and a well made plan of action. It may be easier to manually verify if there are any common ports open on the firewall and then try to scan using one of the well-known ports.
Avoiding IDS:-
In a secured environment you can count on running into IDS and IPS. Properly configured and used as part of a true defense in depth model increases their effectiveness tremendously. This means that the IDS will need to be properly updated, monitored, and used in the proper locations. A penetration tester will be expected to verify that the IDS's are working properly in conjunction with all other security controls to properly protect the environment.The primary method of bypassing any IDS is to avoid signatures that are created to look for specific patterns. These signatures must be fine-tuned to find only positively malicious behavior and should not be so restrictive that alerts are triggered for normal traffic patterns. Over the years, the maturity level of these signatures has increased significantly, but a penetration tester or knowledgeable attacker will be able to use various means to bypass even the most carefully crafted signatures. In this section, we review some of the methods that have been used by attackers in the wild.
The primary method of bypassing any IDS is to avoid signatures that are created to look for specific patterns. These signatures must be fine-tuned to find only positively malicious behavior and should not be so restrictive that alerts are triggered for normal traffic patterns. Over the years, the maturity level of these signatures has increased significantly, but a penetration tester or knowledgeable attacker will be able to use various means to bypass even the most carefully crafted signatures. In this section, we review some of the methods that have been used by attackers in the wild.
Canonicalization Technique:-
Canonicalization refers to the act of substituting various inputs for the canonical name of a file or path. This practice can be as simple as substituting hexadecimal representations ASCII text values. Here is an example of an equivalent string:
• String A in Hex: "54:68:69:73:20:69:73:20:61:20:73:74:72:69:6e:67"
• String A in text: "This is a string"
• String A in ASCII: "084 104 105 115 032 105 115 032 097 032 115 116 114 105 110 103"
By taking advantage of the fact there are sometimes literally thousands of combinations possible for a single URL. To put this into perspective, let's take a look at the address we can use to get from our browser to our local Ubuntu Apache server:
#htpp://3232240651/
Luckily, this address confuses our Apache server and we receive the following message:
The previous request attempted to load the local page at 127.0.0.1. Let's see what occurs when we try to load the remote pfSense administration console in the same manner:
#http://2130706433/
Here we are warned by the web server hosting the pfSense administrative console that a potential DNS Rebind attack occurred:
Let's try something else that actually works properly:
In the console, ping one of the addresses we listed above:
#ping 3232240651
As we can see, the IP address resolved properly and we receive our replies as expected. This very same concept is key when trying to bypass an IDS rule. If the type of IDS can be determined, then it should be possible to get the signatures. When reviewing these signatures you would look for opportunities to obscure the URLs, filenames, or other path information enough that it is able to bypass the existing ruleset.