Now you see me, now you don't – avoiding IDS

In a secured environment, you can count on running into IDS and IPS. When these are properly configured and used as part of a true defense in-depth model, this 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.

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 for 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"

We take advantage of the fact that 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:

http://2130706433/

This address translates to our Apache server, and we receive the following message:

Canonicalization

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://3232254721/
Canonicalization

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 preceding addresses we listed:

PING 3232254721 (192.168.75.10) 56(84) bytes of data.
64 bytes from 192.168.75.10: icmp_seq=1 ttl=64 time=9.34 ms
64 bytes from 192.168.75.10: icmp_seq=2 ttl=64 time=0.265 ms
64 bytes from 192.168.75.10: icmp_seq=3 ttl=64 time=0.292 ms

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 so that it is able to bypass the existing rule set.

Tip

Try this out with commonly found websites. Many web servers will properly interpret these URLs and serve the page. This can be interesting when used in combination with social engineering campaigns as well. Obscuring a URL in a phishing e-mail will lead to more clicks from users who are not properly trained.

Timing is everything

In the previous chapters, we have already mentioned that timing can be critical when performing a network scan on a secured environment. Using Nmap, we can adjust the number of packets that are sent in a given timeframe. IDS signatures look for patterns, and sending packets out to many machines in a short timeframe is a definite pattern.

When attempting to bypass these mechanisms, it is important to understand the logic behind the devices and how they work. If your traffic does not match what is normally seen on a network, there is a good possibility that you will be blocked before there is a chance to gain much information. This can be frustrating at best and lead to a failed assessment at worst. Take your time and plan out the stages needed for a successful test. It is better to start off slow and determine which type of security mechanisms are in place than to rush in and hit every possible port in the world and get your testing IP ranges auto-banned.

Nmap and many other tools have the granularity and ability to restrict the timing of your scans. It may even be advisable to begin with a manual-controlled network enumeration of specific ports that are suspected to be open rather than starting with an automated scan.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset