Bring out your disco ball, your leg warmers, and your VHS tapes! While a lot of us watch the VH1 hit “I Love the 80s” for pop culture, I’m always drawn to the old tech. As such, let’s focus on bringing old hacking tricks to new a new audience of pen testers. I’m reminded of a quote from George Santayana, “Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direction is set for possible improvement: and when experience is not retained, as among savages, infancy is perpetual. Those who cannot remember the past are condemned to repeat it.” This last portion of the quote has been used in variants for quite some time, but why do I bring this up in a hacking retro tutorial?
About two years ago after a workshop I ran at DefCon 24, I had a discussion with my co-presenter about some of the material we had presented. Specifically, I was laughing about one of the tools we discussed and the fact that I had originally learned about it during one of the first SANS conferences I had attended… back in about 1999. Yes, that is seventeen years, and we were still talking about that tool. At first thought, you would think there would be a more modern tool to talk about, or that companies would have learned by now to fix the vulnerabilities identified by the tool (wishful thinking, I know). So before I go into greater detail about the tool we used during the workshop, let me provide a bit of foundation for why we used the tool and why it’s still relevant today.
Hacking Retro – spective
The topic was “Intrusion Prevention System Evasion Techniques”, and we were providing the education to students to help understand the effort necessary to bypass defensive techniques utilized by network and system administrators. As most of us know, when conducting a penetration test we will identify systems that are blocked by the customer through the use of network security devices. We also know that the vulnerability scans will show that all ports are blocked on those protected systems, which leaves the impression that the systems are impervious to attack. However, we know that simply adding firewalls do not remediate vulnerabilities on systems, and they remain unprotected against attacks – and as security professionals this knowledge needs to be transferred appropriately to the customer. With that mandate, here’s the example we provided to students at our workshop:
Figure 1 Workshop Systems Defined as Internet
If you look at the illustration, the students of the workshop are labeled as the “workshop systems” and their task was to gather information about the vulnerable system behind a firewall. To further complicate the scenario, the firewall included intrusion detection capability. This is similar to an attacker attempting to glean information across the Internet of a particular client site. Snort is a well-known Intrusion Detection System (IDS) and many are familiar with its rules.
The screenshot below shows attempts being blocked for HTTP (80), FTP (21) and IMAP (143).
Figure 2 – Snort Blocked Attempts
Although this screenshot provides us some detail regarding attacks, let us take a look at the Snort Rules directly to better understand exactly what the IDS is doing. In our scenario, we are going to conduct scans on systems behind the firewall. If caught, the following rule-set will detect and block our scans (or at least that is what corporations want to believe):
Figure 3 – Snort Rules
As you can see, there are 8 different types of scans that will trigger an “attempted-recon” alert. If you were to look at the snort rule itself, you would see the following:
Figure 4 – Snort Rules Viewer
You can see how the rule maps to the previous image, in that the alert is specifically for PSNG_TCP_FILTERED_PORTSCAN, and the “sid: 5” is the reason a connection is being blocked by Snort.
So any scans would be prevented, correct? Well, we know that’s not true. Let’s find out exactly why, and begin our scans within the lab. Below we run a typical Nmap scan against the backend systems.
Figure 5 – Nmap Typical Scan
We can see that the scans aren’t getting anything, so let’s take a look at the IDS console:
Figure 6 – Snort Console
As seen above, the scan is blocked by pre.process rules targeting TCP scans. At this point, the IDS is doing what it’s supposed to do – block scans. So how do we get past this? If you look below, you’ll see I modified my scan, and I now know that ports 80 and 21 are open. BUT… this took 37 minutes to complete. Not cool. Especially if we need to perform this type of an attack against a large enterprise.
Figure 7 – Nmap Results
At this point our presentation got into traffic manipulation, and you’ll see that you can eliminate the time to conduct the scan quite significantly below:
Figure 8 – Faster Nmap Scan
And NOW, we get into the whole reason behind this article… Fragrouter. Even though it’s been decades since fragrouter was released, we can see that it still has relevance to today’s penetration testing efforts. By implementing the -T5 option on fragrouter, we were able to conduct our scans in the same amount of time as if there were no IDS present at all. How did we do this?
Figure 9 – Fragrouter
Hacking Retro is New Again
What makes this whole story, including the use of fragrouter, so interesting is that students have made statements in other courses I’ve attended that they thought the information being presented in one of courses was old and outdated. Two thoughts:
- Yes, the information is old, BUT…
- The information is still extremely relevant.
I have been a person that constantly goes back through prior training course material. The reason isn’t necessarily the training, but identification of foundational elements that constantly present themselves as you go through your career. This is the same foundational knowledge that is the primary impetus for the development of advanced technologies.
Any good penetration testing course will detail steps that utilize search engines, information gathering via DNS, port scanning, enumeration, and vulnerability exploitation. Why? Because these fundamentals are still valid. These are the same topics and tools used by hackers for many, many years. Google has been around for nineteen years. The use of ‘dig’ has been around since the late eighties. Nmap has been around since 1997. The Nessus Project was started in 1998. Netcat, tcpdump, and John the Ripper have also been around for years and haven’t changed much over time. Interestingly enough as you look back over the previous slides you will notice we used nmap quite often as a comparison. The reason behind this is simple: The tool works! It is a great comparison to other tools, and many individuals understand it because they use it quite often. I laughed about fragrouter, but nmap has been around since 1997, which is an even longer time frame. Are they old? Yes. Are they outdated? Hardly.
I will never argue that changes can’t be made, but if we look back at the earlier quote, “Progress, far from consisting in change, depends on retentiveness.” We need to retain the foundational knowledge and concepts from these training courses and should reject the belief that these things are old and outdated. In fact, the opposite often proves itself true.
Experience Rules the Day
A couple of years ago, I was performing a penetration test and came across a Windows XP system. Seriously. Fortunately, I had kept up to date on not only the newer attack vectors, but had refreshed myself on the older ones as well, and rolled that puppy over like a champ in a matter of minutes. Was it simple. Oh yeah… but not if I was new to the profession and thought learning old techniques was a waste of time. My co-worker would have lost all respect for me if I had struggled exploiting that Windows XP system (and rightly so!).
I believe this is especially interesting, because it was when Snort was still new. We used Snort to monitor and maintain security, because there were instances of the use of fragmentation being used to get past network firewalls at that time. The issues within the organization were eventually fixed, but years later we found that similar instances were finding its way into wireless access points. Why did this issue repeat itself? Because the company didn’t have the same personnel who had fixed this issue in the wired network world to prevent it from happening in the wireless world when it was implemented. Therefore, the same mistakes were repeated. As mentioned in the beginning of the article, “Those who cannot remember the past are condemned to repeat it,” and, as professional penetration testers, we need to be ready to exploit our customer’s failure to learn from the past, by making sure we retain the knowledge of the past.
Todd Kendall is an Associate Director at Cognizant for Threat and Vulnerability Management. Todd is an experienced security consultant in the commercial security world, as well as within the highly secure networks for the Department of Defense (DOD). He has been tasked with security policy development, network security design and review, vulnerability assessments, penetration testing, and intrusion detection, analysis, and response, router and switch configuration, firewall configuration and management, enterprise management systems, software implementation, hardware configuration, wireless reviews and forensics. He is also responsible for performing vulnerability and risk assessments on operational networks within the finance, healthcare, airline, utility industries, as well as migration into Cloud environments.
*** This is a Security Bloggers Network syndicated blog from The Ethical Hacker Network authored by Todd Kendall. Read the original post at: http://feedproxy.google.com/~r/eh-net/~3/rbfdXImXLVk/