BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Remote connectivity to network resources has become a staple for many employees of modern enterprises. Whether...
the connection is conducted via VPN, remote desktop or Secure Shell (SSH), it will unavoidably traverse a network path laden with routers, switches and firewalls, many of which can be easily compromised.
Once an individual obtains any type of management access to a router or switch, the simplicity with which they can create havoc is astonishing.
Much to the dismay of administrators and organizations within the security industry, nefarious individuals are cognizant of these devices' vulnerabilities as well -- and any malicious person who has basic networking knowledge can successfully hack routers, switches and firewalls to steal corporate information and disrupt communications.
In this tip, we will explore why these devices are easy targets; how many of today's malicious network attacks against routers, switches and firewalls are carried out; and what an enterprise can do to defend its network from them.
Attacking a Cisco router or switch
The process of routing and switching, at its core, is nothing more than moving packets in, out and around the network. Because of this basic process, routers and switches are often considered to be simple pass-through devices. However, it's important to note that once an individual obtains any type of management access to a router or switch, the simplicity with which they can create havoc is astonishing.
To begin, let's look at one of the ways a router or switch can be attacked. The vendor that maintains the lion's share of the routing and switching market is Cisco Systems Inc. While Hewlett-Packard Co. and Brocade Communications Systems Inc. have made impressive progress within the Layer 2 switch market, Cisco is still considered the gold standard by many within the networking industry. Yet, because Cisco products are so widely used, they are also among the most targeted.
More on router, switch and firewall security
Firewall security tips
Router security tips
Switch security tips
For example, in the BackTrack 5 Linux distribution -- which comes equipped with a number of security features and software to help security administrators perform penetration testing and find vulnerabilities in a wide variety of systems -- there is an entire section of the toolset devoted to Cisco devices. While these tools are meant to be used for auditing, they are often used by attackers to identify the existence of any number of rudimentary vulnerabilities, such as password weaknesses, which can be checked by John the Ripper.
Fortunately, BackTrack 5 (release 3, as of this writing) is available to enterprise security pros as well. If you haven't installed BackTrack yet, start there. Then, to begin seeking out vulnerable network devices (after you've gained permission to do so, of course), navigate to the following directory:
Run the Perl file called cge.pl without any options. Depending on what version is running, up to 14 different options should appear on the screen, each referencing a script that attempts to exploit a different vulnerability. Since it's far more effective to test the external-facing interface of the router, enterprises should always test it as this. Assuming the router being audited has an external IP address of 184.108.40.206, type in the following command:
./cge.pl 220.127.116.11 2
This runs the exploit against the external interface utilizing option two, Cisco IOS Router Denial of Service Vulnerability. If the router is vulnerable, a message will be displayed in standard output, such as: Vulnerability successfully exploited. Target server is down…
What becomes readily apparent is that the sheer number of Cisco exploits, neatly packaged together within one platform, can be extremely dangerous in the wrong hands. The above example is simply one of many exploits currently available. So, if it's not near the top of your to-do list already, run through this exercise and carefully note the results; you'll need them for remediation efforts not long after.
The threat of BGP redirection
Another potential danger in utilizing networked equipment is data loss. While attacks can be accomplished several different ways, a method known as Border Gateway Protocol (BGP) redirection has become increasingly troubling.
To begin, BGP is considered the core protocol of the Internet. Used by gateway hosts, BGP exchanges the routing information and unique identifiers known as Autonomous Systems Numbers (ASNs) that are assigned by either the Internet Assigned Number Authority, or IANA, or Regional Internet Registries, or RIRs. When packets cross an ISP's gateway, the gateway can identify which ISP an individual packet came from by examining the ASN in the packet's header.
Many times, nefarious individuals will advertise routes or ASNs they know belong to organizations within another Autonomous System. For example, if a bank belongs to AS1 and a malicious person operates a BGP-enabled router within AS2, he simply needs to disguise his router as AS1, and much of the traffic destined for AS1 will be redirected to AS2 instead. This is a rather simplistic example, but the exploit has become extremely easy to carry out.
Getting beyond the firewall
Previously, I alluded to the catastrophic consequences of a network attacker obtaining management access to a router or switch. Words cannot sufficiently express how true this is in terms of firewall management access. The firewall is the primary defensive mechanism for any enterprise network, so if an attacker gains the ability to turn it off or even to manipulate it to allow certain traffic, the result could be disastrous.
For example, assume that the subnet 18.104.22.168/24 is considered malicious and that the security administrator has dutifully configured the access control list (ACL) to block all inbound and outbound traffic to that subnet. If a nefarious individual successfully obtains management access to the firewall, they could wreak havoc with authorized network traffic, and certainly foster all sorts of malicious traffic and system requests. Altering the ACL to permit traffic to the above-mentioned subnet is merely an academic exercise as all manner of havoc can be wreaked by said nefarious individuals.
The human factor
Not infrequently, various firewall vendors publish known vulnerabilities for which a patch may or may not exist. For example, the Cisco Security Advisories, Responses and Notices site provides a convenient database that allows end users to stay up to date with the latest security issues pertaining to all Cisco products, including firewalls. I find that Cisco is typically pretty good about fully disclosing known vulnerabilities and even better at creating patches. Much of this has to do with the fact that Cisco invests a significant amount of research in assessing the security posture of their products.
In short, if an organization has a Cisco infrastructure, there really is no excuse for not being up to speed with the latest vulnerabilities. Many organizations fail to dedicate specific personnel for the monitoring of newly released patches and/or vulnerabilities, and much of this has to do with their reliance on Cisco and other like-minded vendors to let them know of these issues in a timely manner. Needless to say, this approach is seriously flawed, but is nonetheless an approach system administrators must face on a daily basis. Therefore, whoever is responsible for the successful administration of an organization's firewall infrastructure must do everything he or she can to stay up to speed with regard to patches, vulnerability monitoring and any other issues that may arise.
Preventing router, switch and firewall compromises
So, how does one protect an enterprise network from being compromised via a router, switch or firewall? In the first example above, frequent auditing should be the rule of the day. Start with Backtrack and utilize the rich assortment of tools within the platform. Be sure to perform updates when required and ensure that factory default passwords are completely done away with. Cisco is known for having a default username of cisco and default password of cisco.
With regard to the BGP vulnerability: This is most effectively addressed at the ISP level. Research has been conducted regarding the utilization of a public key infrastructure (PKI) between Autonomous Systems, also at the ISP level. At the network level, the best course of action is to monitor the routes of incoming packets and search for anything anomalous in them. For example, are there packets that appear to be coming from Autonomous Systems that your ISP does not accept routes from? This may require a consistent dialogue between system administrators and officials at the ISP.
In addition, I like the idea of placing an organization's router behind a well-configured firewall, but then configuring the router with tightly enforced ACLs -- this way, the burden is not completely on the firewall.
In terms of best practices for avoiding firewall compromise, strongly consider blocking all inbound and outbound traffic by default, and encourage the end user to justify why certain traffic should be allowed through the firewall. Also, strictly enforce control over who has out-of-band management access to the firewall, and from where each administrator is allowed to access management functions. In other words, certain people may be authorized management access to the firewall, but operational security may dictate that they be allowed to access management resources only from within the LAN -- as opposed to accessing them from their residence or outside the country. Lastly, monitor, research and stay abreast of the latest updates, patches and security vulnerabilities pertaining to your existing firewall infrastructure.
Keeping the above-mentioned suggestions in mind, security administrators must stay vigilant with regard to how their routers and switches are configured to ensure not only that strict controls are adhered to but also that performance does not suffer. To do otherwise could mean the difference between being a victim and being a survivor.
About the author:
Brad Casey holds a Master of Science degree in information assurance from the University of Texas at San Antonio and has extensive experience in the areas of penetration testing, public key infrastructure, VoIP and network packet analysis. He is also knowledgeable in the areas of system administration, Active Directory and Windows Server 2008. He spent five years doing security assessment testing in the U.S. Air Force, and in his spare time, you can find him looking at Wireshark captures and playing with various Linux distributions in virtual machines.