At this point, you are an educated script kiddy. You are still relying on other people's code, but you should understand the workings of most tools you're presented with. In this section we will present some guidelines for applying --and expanding --your knowledge.

Designing an attack is rarely a straightforward procedure, and initiating an effective one requires as much intuition as education, something that can only be taught through experience. Every network and server you encounter is going to be unique with its own strengths and weaknesses, and your desired effect may vary. Distributed denial of service attacks (DDoS), for example, tend to rely more on viruses and botnet (for an interesting and scary introduction to botnets, check out [1]). Theft from an individual source will probably be more directed, possibly even requiring access to the physical network. Regardless of the intention though, any attack tends to be broken into distinct phases with distinct goals.

We've already examined tools like nmap, ethereal, and netcat (as well as ICMP-based tools like traceroute), which can give us information about the network and network settings of our target. Xprobe2[2] is a handy program that tries to calculate the operating system running on a computer. This can be a great launching point for deciding a method of attack. Recall that different operating systems different implementation of the network stack. Xprobe2 examines TCP/IP responses as well as ICMP packets to make a reliable estimate of what type and version of OS a target is running. Running xprobe is as simple as pointing it at a target:

As you can see, Xprobe makes several additional guesses, since some implementations are very close or identical. Computers set to drop all ICMP packets may be unidentifiable with default settings. The following options specify to only use module 11 (the TCP handshake), to attempt it on port 80, and to assume that the port is open:

Success. We can now look into Linux specific attacks for kernel 2.6.11.

Reconnaissance doesn't need to be high tech. Professional attackers will use any means to gain access to their target, from dumpster diving to video surveillance to actually getting hired as or posing as an employee. These methods can be time consuming or expensive (or messy) but often expose an unprotected interior. The effective sysadmin must be aware of this and properly instruct colleagues (and bosses) as to proper secure behavior[3].

Usually if you're attacking a system without permission, you don't want to get caught. You can avoid this in many ways, again with both low and high tech approaches. Some low tech examples: stealing the scrap of paper your colleague wrote their password on, then logging on via a public terminal, or committing your dastardly deeds from an internet cafe (in another state even). This way, when a suspicious/furious sysadmin attempts to track you down, they get sources that can't be linked to you.

A more high tech method is to bounce your attack through many intermediary sources such as by sshing through several dummy accounts. This is hardly as glamorous as it appears in movies with the ticking countdown until discovery or dotted lines on world maps. The problem with this method (conveniently ignored by Hollywood) is that even after you disconnect, persistent sysadmins may still be able to trace the origin back to you. The trick however is the effort and cooperation necessary. If the communication traveled through three different networks owned by three different organizations, the sysadmin has to get in touch with and convince three different companies to provide her with access to their logs, something they probably won't be eager to do.

Deleting the logs in question can make the trail go immediately cold (or keep the attack from ever being noticed). Doing this usually requires administrative privileges and knowledge of where the logs are located (/var/log/ is the standard log directory, but they may be elsewhere and not obviously named), but if the option presents itself it shouldn't be squandered. That said, it's no guarantee you're off the hook. Sysadmins use IDS's (intrusion detection systems) and other tools to alert them (often via pager) to suspicious behavior, so even deleting the logs may not be enough if they've already been forwarded to another source and the admin has been woken up.

What can we do safely from our lab? The short answer is "anything". The longer answer is "anything we have access to and are willing to set up". Because we're operating with a wired isolated network, we can be quite certain our malicious content won't escape, nor will a hapless innocent stumble in without our noticing. There are times however when we want to study exterior "real world" subjects. Be sure when connecting the lab to the school network that all potentially disruptive apps are disabled. Remember that discretion is the better part of valor, and if you're uncertain whether your actions will result in angry calls to/from the Marlboro IT department, you shouldn't risk it. Activities like port scanning are fairly unobtrusive and are usually ignored. Trying to brute force the wrong person's password could get you in a lot of trouble.

There are a lot of essential topics we haven't covered in this course. Network programming knowledge is key to creating your own network auditing/attacking tools, and is a logical application of the theoretical networking done in the first weeks. Buffer and stack overflowing, usually targeting old C code, is a very complex (but rewarding) subject that allows you to actually exploit poorly written programs (as opposed to the merely poorly configured ones we've dealt with). It (generally) requires learning assembly language, which is a serious undertaking itself.

One of the best methods to explore vulnerabilities is by exploring the Bugtraq archive[4]. This archive reaches back over a decade and often includes "proof of concept" code. Since much of the affected software (such as old versions of Apache) is open source, you can both execute the exploit and see why it works.

1) http://www.wired.com/wired/archive/14.11/botnet.html
2) http://xprobe.sourceforge.net/
3) Skoudis, Ed, Counter Hack, Prentice Hall PTR, 2002
4) http://www.securityfocus.com/vulnerabilities

http://cs.marlboro.edu/ courses/ fall2006/networking/ private/ tableofcontents/ AttackAnatomy
last modified Monday April 2 2007 9:30 pm EDT