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:·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. You will also need to understand the automated methods of
detection such as web applications, network, and host-based intrusion detection
systems that are in place to avoid triggering alerts.
Note: - When pentested with the
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.
Lab
preparation:
This is critical to
being able to learn and practice the latest and greatest techniques as the
excellent minds in the security research field continue to surprise us with new
vulnerabilities and possible attack vectors. This article cannot cover every
possible method of testing a network, but building the labs is an attempt at
adding long lasting value that will hopefully lead to a lifetime of the
"hacker mentality".
If you continue to
build out your personal lab and increase the difficulty of the practice
challenges that you set for yourself you will quickly become comfortable with
testing any sort of environment.
Kali
Linux, m0n0wall firewall, and Metasploitable virtual machines should be
configured in the following manner:
We use virtualbox for our lab
preparation.
Kali Linux guest machine configuration:
This
machine will need to be connected to the 192.168.20.0/24 subnet. In the Oracle
VM VirtualBox Manager console highlight the Kali Linux and select the Settings
option
from the top navigation bar. Ensure that only one network adapter is enabled.
The adapter should use the Vlan2
internal network option.
Metasploitable guest machine configuration:
The
Metasploitable machine will be used as the target. It needs to be configured to
connect to VLAN1, which is an internal network. To create an internal network
you will need to manually select VLAN1 into the network configuration screen in
the Oracle VM VirtualBox Manager. Your settings should be similar to the following:
M0n0wall guest machine configuration:
Configuring
our firewall is a little bit complicated. 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
three network adapters. One will be used for the NET, VLAN1 segment and the other
for the VLAN2 segment. NET will be treated as an untrusted wide area network.
- In VirtualBox use the following settings to set up a new guest machine:
- Name: M0n0wall_Base_Install
- OS Type: BSD/FreeBSD
- Memory: 128 MB
- Virtual Hard Disk: Start-up Disk checked, Create New Hard Disk selected
- Create New Virtual Disk: VDI
- Virtual Disk Storage Details: Dynamically Allocated
- Virtual disk file location and size: (Locate in a folder to be used for future labs), 200 MB in size
Network
Adapter should be similar to the following:
· Network Adapter 1 should be configured to use NAT which will be our WAN connection.
· Network Adapter 2 needs to be configured for the Internal Network name VLAN1
which will represent our LAN connection and.
· Network Adapter 3 should be set up at Internal Network name VLAN2 and will be tied to our internal network (the OPT device).
Now start m0n0wall guest machine. M0n0Wall will need to be installed on the new VirtualBox Machine.
·
Choose the 7) Install on Hard Drive option
When asked which hard drive to install on,
choose your hard drive (in this case it is ad0).
· Reboot when prompted and ensure that the
system is booting from the hard disk install rather than the ISO (remove ISO
file from cd/dvd device).
Now that
M0n0Wall has been installed we must configure the interfaces:
· Choose 1)
Interfaces: assign network ports and press Enter.
· When prompted with a listing of available
interfaces continue by setting up your VLANs. Press y to continue.
Continue
through the creation process for each adapter. In this case our lnc0
adapter
is assigned to VLAN 1, lnc1 and lnc2
to
VLAN 3.These VLANs can be any unused number between 1 and 4094.
When determining the LAN interface name choose
the adapter that is assigned to VLAN1, the WAN adapter should be assigned to
the NAT adapter, and the VLAN2 adapter should be assigned as the OPT device.
· Reboot the firewall to save your changes.
The firewall
has been installed on our hard drive and the adapters have been assigned to
VLANs. Now we need to set up the LAN IP address and connect to the web
interface for further configuration.
· - Select option 2) Set up LAN IP address and press Enter to continue.
- When prompted type the IP address you would like your LAN to use. We will choose 192.168.10.1
- Next is applying LAN subnet, in this case we set to 24.
- Next is asking for DHCP server on LAN. Type y for enable, now apply start ip address and end ip address range as shown bellow.
Now boot Kali Linux and set manually ip address. As
the m0n0wall machine will need to be our router as well, we need to set it up
as the default gateway as shown bellow.
We can now boot up another Kali Linux on the VLAN1
internal network and connect to the web interface of the firewall by first setup
a new IP address on the appropriate range and then directing our web browser to
http://192.168.10.1. Default
username, password is admin and mono respectively.
We need to set
up our other interfaces to perform the tasks we have in mind which is to
provide the 192.168.10.0/24 subnet with a
firewalled route to our vulnerable host which will be located at 192.168.10.2
(connect a Metasploitable machine to VLAN2).
Select
the OPT1
interface from the navigation menu on the left of the
screen and enable it by checking the appropriate box. Leave the Bridge
with option as none
and type the IP address for this interface: 192.168.10.1. Ensure that the drop down
lists 24.
Click on the Save button after applicable
changes have been made as shown bellow.
We can enable the DHCP server on the OPT1
interface. Choose DHCP server on the left
navigation menu and chose the OPT1 tab
under Services: DHCP server.
Check the box that enables the DHCP service on this port and enter the Range
as 192.168.10.2
to 192.168.10.254.
After your changes have been selected click on the Save
button
to continue.
Choose Firewall | Rule
on
the left navigation menu. By default the WAN interface should be blocked from connecting
internally as there are not pre established rules that allow any traffic
through. We go to edit menu (e).
And uncheck Block
private networks. Apply the Changes and return to Firewall
| Rules.
For testing purpose, we will go to OPT1 tab and enable ports 80, 443, 21, 22, and allow ICMP. Add the rules as follows:
Click the Firewall Rules option in the left-hand navigation bar and select the OPT1 tab. Selecting the icon that looks like a plus (+) symbol within a circle will bring you to the screen that allows new rules to be configured. Click on this icon to continue.
-> Use the following rule settings to enable ICMP pass-through:
-> Click on the Apply Changes button at the top of the screen.
Click the Firewall Rules option in the left-hand navigation bar and select the OPT1 tab. Selecting the icon that looks like a plus (+) symbol within a circle will bring you to the screen that allows new rules to be configured. Click on this icon to continue.
-> Use the following rule settings to enable ICMP pass-through:
- Action: Pass
- Interface: OPT1
- Protocol: ICMP
- All others: Default
-> Click on the Apply Changes button at the top of the screen.
·
Use the following rule settings to enable
HTTP pass-through.
o
Action: Pass
o
Interface: OPT1
o
Protocol: TCP
o
Destination port range: HTTP
Continue
adding ports until the configuration matches the following:
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
Stealth scanning through the firewall:
Firewalls are a
great security mechanism when used in conjunction with other security controls;
however, they must be properly maintained and monitored to be truly effective.
There are several mechanisms that can be used to attempt to bypass these
devices.
It is important
to know where you are being blocked when scanning. When testing through a
firewall it may become difficult to prepare a stealthy attack if you do not
have all of the information. Remember that tools such as Firewalker or Hping
can assist with determining where the block occurs and if the port is truly
available or jus
t closed.
T
raceroute to find out if there is a
firewall:
Sometimes
we can use traceroute to see the path to the target system. Let's take a look
aatt open raceroute from VLAN1 to VLAN2.
Looking at
this result we can see that the first hop goes through our gateway at 192.168.20.1
before being routed to the host.
Finding out if the firewall is blocking certain ports
using 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 Identification | Hping3.
It can also be invoked at the command line by simply typing: hping3.
Hping3 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.
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.10.2 -p 80 10.10.10.2
This command
will spoof 10 packets from 192.168.10.2 to port 80 on 10.10.10.2. This is the basis for an idle scan and if successful would allow you
to hping the 192.168.10.2 machine to look for an increase in the IP sequence number.
In this case
we could enable monitoring on them0n0wall 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 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.
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. 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.10.2
which
we know is behind our target firewall.
We were able
to determine which ports on the firewall were open (21, 22, 80, and 443). 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.
These
tools use TTL to determine if a port is open or not and as our gateway is on
the same machine as our firewall and router the results are varied and
obscured.
Idle scans
remain the best method of determining what is behind a properly locked down
firewall.
Avoiding IDS:
In a secured environment you can count on running into IDS and IPS. 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.
Canonicalization:
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 Apache server:
http://2130706433/
Luckily, this
address confuses our Apache server. And give 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 m0n0wall administration console in the
same manner:
http://
3232238082/
Here
we are warned by the web server hosting the m0n0wall administrative console
that a potential DNS Rebind attack occurred:
In the console, pings one
of the addresses we listed above:
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.
4 comments:
Mastering Kali Linux for Advanced Penetration Testing - chapter 8
Mastering Kali Linux for Advanced Penetration Testing - chapter 8
@Anonymous Thank you for providing source since it was a guest post, I was not aware if any instance of this article has been taken exactly in the same manner from any book.
I appreciate your efforts. Thanks once again. Have a good day.
Damn I 've made a mistake it was: Advanced Penetration Testing For Highly-Secured Environments - chapter 8.
Post a Comment