On the consumer side, we expect the manufacturer to apply thorough checks to the products they release on the market. One would think that the IT world is somehow similar and that the same level of scrutiny is undertaken by the product before it reaches the shop floor. But this is not so, and as the perfect example of a product range from one rather famous monopoly demonstrates , such a product can have as many security holes as a Swiss cheese and choose to refuse to work on a random basis or operate in a slightly different manner than anticipated.
In case of an open source product, you can trace the problem to the code, make a patch, and submit your findings to the developer for inclusion in the mainstream release. On the other side, when the source is not available for your analysis, you are pretty much stuck with contacting technical support or reporting the problem to the developer. Since you have paid your hard-earned money for this hardware or software, at the least you would be disappointed with a situation when you get "owned" through no fault of your own, purely because someone in the testing and development team did not correctly follow procedures.
In the network devices marketplace , Cisco has a reputation for producing good quality systems, with particular emphasis on stability and security. Still, no sky is as cloudless as it may seem. Despite all the thorough testing of the current and new I/Pix/Cat/OSes, the underground community finds new vulnerabilities in the Cisco product range on a rather frequent basis. Apparently, recent years have seen a steady increase in the number of bugs being released (see Figure 3-1). This might be partially explained by the growing number and popularity of the Cisco devices and the increasing complexity of the supported features. It seems that by expanding into the new areas (for example, wireless and small office/home office [SOHO] networks) and acquiring new companies (for example, Airospace Inc. and Linksys Group Inc.), Cisco somehow managed to diversify the preproduction testing efforts among the new divisions, potentially reducing the stability of these platforms when compared to a more mature range of traditional Cisco products.
The blind trust in the vendor-testing procedures may not be enough or may simply be unacceptable for the mission-critical environment in which the devices are going to be run. Unfortunately , when dealing with some monopolistic corporations, chances of your being granted access to source based on your individual request are extremely slim. Besides, the cost and effort required for such an analysis is usually more than what a single individual can do. However, you can always do a "black box" assessment of the device, looking at functionality of the device under certain artificially caused conditions. It is a good idea to perform such testing before the device is installed on a high-security -level production network.
The Arhont team has prepared a network device security evaluation template that in our view covers most of these evaluation scenarios. This template can be used for standalone device security testing or it can be incorporated into a more general security audit, internal penetration testing included. (See Appendix A for more details.)
Let's take a brief walk through the networked appliance evaluation process. Nowadays, it is a common mistake to pay little or no attention to the examination of the possible security flaws of the lower network layers of the device operation. It is also a typical practice to accept that the Layer 2 attacks usually happen within the same network segment; unfortunately, this is not necessarily true. First of all, an incorrect implementation of the Layer 2 protocols may render the rest of your defenses useless, allowing an attacker to incorporate the discovered weakness to progress further into the device cracking. On the other hand, with the spread of the wireless technology, your LAN might intentionally, in case of the improper WLAN design, or accidentally , in case of the clueless user plugging the Access Point (AP) into the switch socket, spread well past the physical boundaries of your building and beyond your control. The most typical types of attacks performed on Layer 2 include sustainability of the CAM table flooding and VLAN jumping on switches, abusing incorrect handling of the corrupted data frames , cracking Layer 2 encryption on the 802.11x wireless networks, and stealing 802.1x user authentication credentials.
Looking at the network layer, you can split the assessment into several categories. One of the most important parts will include the analysis of handling Layer 3 attacks directed to the device itself. This will include analysis of the protective features of the firewall, handling of the oversized IP datagrams and fragmentation attacks, IPID and sequence number predictability, and so forth. Furthermore, you should look at security handling of both routing and redundancy protocols, in particular at the possibility of malicious route injection, improper authentication during the route information exchange, susceptibility to Internet Control Message Protocol (ICMP) redirection attacks, and handling of loose and strict source routing IP options. Additional attention should be paid to correct implementation of the Layer 3 VPN tunneling protocols such as IPSec and PPTP. We will look at each part in more detail in the later chapters of the book.
Assessing the security at the application layer of the Cisco devices is considered to be somehow limited as opposed to the rich field of possibilities at the transport and lower layers. This is mainly due to the nature of the core function of these devices on a network. However, several vulnerabilities were found both in the implementation of the application services and the application protocols themselves as such. An example of such a vulnerability that is still a real-world threat is the possibility of hacking into Cisco routers running older IOS versions via the router configuration web interface. We can also mention the claims of inclusion of a backdoor SNMP community in one of the IOS images and backdoor account in Cisco WLSE/HSE wireless appliances. A typical weakness of static testing of the application running on the device lies in its inability to take into consideration the specifics of the running environment. An application security assessment, in the ideal condition, should evaluate applications at the code level, as an effective assessment should use an expert toolset and specially crafted methodology to examine rigorously each opportunity of intercourse with the application. It should also test the underlying device software with respect to the particular hardware on which it runs, as well as the logic organization of interaction between the two. In particular, this applies to the remote configuration services such as Telnet, SSH, SNMP implementations , and device web interfaces.
In black box device security assessments and penetration testing, we are pretty much limited to throwing everything but the kitchen sink at the services open on the network appliance using netcat, your favorite hex editor, and a variety of testing tools that generate common data input validation conditions (such as the famous . ./. ./ ). Well, something is still better than nothing, and judging by the number of vulnerabilities uncovered, it works.