With your high-value targets identified, you can begin to understand what the attack points and vectors are to your environment and sys-tems.Attack pointsare defined by what architectural exposures or means are available for someone to gain access or bypass controls.Attack vec-torslook at these points with regard to the human threat, whether it is an anonymous Internet user, a customer, an employee, or an administra-tor. Combined and applied at each progressive level, the attack points and vectors are used to model attack trees. This approach has been used in the past by inventors and designers to “build a better mousetrap.”
Bruce Schneier used this process to model attack trees against computer applications and highlighted areas where the attack trees can be as-signed a variety of values; it is available online athttp://www.ddj.com/
documents/s=896/ddj9912a/9912a.htm. Figure 3-2 takes a high-level look at the attack tree present in a relatively simple web application en-vironment.
You must continue to test every possibility upon success of any higher-level attack. That means if you get in on the first try, you con-tinue to assess the other attack points to verify that an exposure does not exist deeper within associated mechanisms.
While an attack tree can be applied against the entire target, the tar-get may be managed by multiple unique groups. Infrastructure and sys-tem remediation is traditionally performed by the internal or outsourced IT department, whereas application remediation is traditionally han-dled by in-house or third-party software developers. It is important to segregate these, as the parties responsible for securing each element are vastly different. Infrastructure and application models provide a delin-eation of responsibilities among unique audiences.
Chapter 3: Hacking Concepts
45
AttackTrees
Infrastructure
Infrastructure attack models can be identified at a macro or micro level.
In this example we focus on those present in very simplistic web archi-tectures. Figure 3-3 shows a common solution used to provide and maintain a corporate web page. The web server is contained in the Cor-porate Homepage cloud on the right side of the diagram. By design, ac-cess to the site itself must occur from the Internet, passing through the Corporate Homepage Firewall only via HTTP over port 80/443. Access to the site from the Corporate LAN itself is routed through the Out-bound Corporate Firewall, which handles all outOut-bound Internet con-nections and back through the Corporate Homepage Firewall. The site is updated by a Content Update Server over a “secure” back channel.
At first glance a system administrator may be concerned only with direct vulnerabilities to the web server; a network administrator may be concerned with only filtering on port 80/443 at the firewall. Neither ad-ministrator has taken into account the risk posed to the corporate homepage as a collective unit. The solution may have a secure web server, but if network controls fail, there will be system-level issues to address. The threats may take the form of attacks on the firewall, attacks on the web server, attacks on the web application itself or the site. Even more importantly there are attack vectors on the inside, potentially ex-isting as disgruntled administrators of the content update server, devel-opers who modify content to be pushed to the web server, administrators
Figure 3-2. Attack tree
of the corporate homepage server itself, and of course, physical controls protecting the server. As you can see, the areas to assess from a security perspective suddenly become more complex.
Application
The application model can more easily be explained at the micro level without supporting elements such as OS, network, or physical, al-though it is critical that these are tuned to provide the minimal access as outlined in the infrastructure model. In this case the application is de-fined as the mechanism delivering authentication, content, and updates to some type of data store. The first step in defining possible attack vec-tors in the application involves mapping out what paths are available to interact with the application and the different components implemented to deliver the content.
Consider a banking application with a functional user portal as well as a separate administration portal. You have two points of attack that may or may not be handled by the same mechanism. You also have a va-riety of controls where equivalent accounts are segregated horizontally,
Figure 3-3. E-commerce network model
such as individual user accounts in a banking application. Next you may have “administration” accounts allowing access to all users ac-counts, or the rights may be segregated into access to saving, checking, loan, and credit card accounts. To complicate things further, add in more granular threats that may include attacks bypassing the authenti-cation methods, performing SQL injection, performing cross-site scripting attacks, bypassing sessioning controls, or bypassing client-side checks at each user level.
This level of testing can be automated to a point, but only intelligent interaction can verify the results of those tests and make the unique modifications to allow compromise, not in accordance to the designed application function.
SUMMARY
At this point you have been exposed to the approach and mindset needed to secure your network against attackers. We have covered the level approach of the hacking model against the network, high-lighting how the overall process links together to infiltrate each layer of protection on your network. Next, we took you a step back to consider how you will take this model and target your network in the most effi-cient means. Finally, we brought both areas together and introduced how they fit together in attack trees at the network and application level. The next step is to hone your technical skills and approach in order to begin assessing your network as described in Chapters 4 and 5.
Chapter 3: Hacking Concepts
47
Summary
Chapter 4
Reconnaissance
49
IN THIS CHAPTER:
■ Collect and Assess
■ Scan
■ Enumerate
■ Application Enumeration
■ Summary
T
he goal of this chapter is to understand how to scan a network to identify target hosts. You will also learn to identify the filtering being performed and attempt to bypass network filtering. Once these basics have been learned you will then progress to learning the basics of identifying services and operating systems on the network, and tech-niques for gathering treasure troves of openly available information.Then, when you are aware of what ports and operating systems exist on the target hosts, you can move on to the process of compromising, as de-scribed in the next chapter.
There are many scanning tools available to perform this type of work on a network. Two of the most flexible for identifying hosts and services are Nmap and Scanline, both with full syntax usage built in to aid you in understanding the commands and in creating your own com-mands. Nmap is the most robust and feature-filled scanner available to date and is supported on both Windows and UNIX platforms. Nmap, created by Fydor, is and always has been a freeware open source scan-ner. The second tool, Scanline from Foundstone, is a freeware command line scanner supported on Windows. Scanline is a second-generation command line utility based on Fscan, updated for speed, flexibility, and accuracy.
In the last part of the chapter, additional enumeration steps will focus on using a variety of native UNIX and Windows commands and third-party tools.