388 Chapter 7 • Hacking Your Own Site Read access, however, is often very practical, if you are able to prop- erly interpret the file format. So although you might have a great deal of difficulty trying to write a new password to a database file by modifying the underlying file directly, reading a copy (if you have that level of file system access) could definitely be useful. Increasingly, a lot of the interesting stuff at a site lives in a database. This is especially true for e-commerce sites. Also, one extremely common programming mistake developers make when developing a Web site is to improperly escape or filter user-supplied data, giving an attacker a way to send SQL commands to a database. Often, an attacker can get a remote shell by feeding the right set of commands to a SQL server. Elevation of Privileges Attacks Ultimately, what any attacker usually wants is higher privileges on the victim machine. If an attacker can gain root on a standard UNIX box, then they can accomplish anything on that box that they want to. More subtle attacks exist, or some that accomplish just the goal of the attacker, but if root can be obtained in an earlier step, then all the other security mechanisms on that machine are essentially turned off. An elevation of privilege attack is an attack against the integrity of the security structure, though it often leads directly to other compromises. If an attacker can gain further capabilities beyond what they were supposed to have, then a security mechanism somewhere has been broken. Such a mechanism may be broken due to a bad design, a bug, or just because the administrator implemented the mechanism improperly. The file access and special file access attacks fall under the category of elevation of privilege as well. If an attacker finds a combination of charac- ters that allows him to roam the server’s hard drive at will, then clearly he’s gone from the intended restriction (remaining within the capabilities of the CGI script’s designer) to having a higher level of access. Some attacks are purely elevation of privileges, though.A classic example is a setuid root UNIX binary with a buffer overflow. An attacker is able to divert the program flow and launch a copy of the shell as the root user. At that point, nothing else has taken place except that the attacker is now the equivalent of root and can continue from there. www.syngress.com 134_ecomm_07 6/19/01 12:02 PM Page 388 Hacking Your Own Site • Chapter 7 389 Another example of a privilege escalation is any service with a hole that yields a remote shell.This kind of hole allows an attacker to go from a position of being able to perform only the functions that the ser- vices provide (which is what the administrator wanted) to being able to run arbitrary commands and poke around the file system. She may be doing so as a user with no special privileges, but it’s much easier for an attacker to gain root access after they have a shell. Performing a Risk Analysis on Your Site Risk is a quantity. It’s a percentage, a probability, a number between 0 and 1.The percentage that represents the likelihood that you’ll be com- promised is a function of three things: vulnerability, threat, and assets. In fact, it’s a product: risk = vulnerability X threat X assets If you are extremely vulnerable (you have lots of holes in your soft- ware) or an extreme threat exists (such as when a government agency has declared information warfare on your site) then your risk approaches 1 or 100 percent risk, meaning that you will get nailed. If your assets are 0, your risk drops to 0 as well, which means you have no business—plus, if your assets are 0, you don’t have a site to begin with. Even if your assets are low (you run a Web site with a picture of your dog), if you are very vulnerable, then you are still at high risk. A worm that automatically exploits common security holes doesn’t know or care that your Web site is just a picture of your dog, it breaks in anyway. You may have a situation where vulnerability is relatively low (you have all the known holes patched away, and you’ve used good judgment when picking products) but may be faced with a dangerous attacker. One example of such an attacker is someone who is capable of finding new holes in software and writing exploits for them, and he isn’t wor- ried about being caught. He might not be worried because he just doesn’t think they will be caught, or perhaps it’s not even illegal to break www.syngress.com 134_ecomm_07 6/19/01 12:02 PM Page 389 390 Chapter 7 • Hacking Your Own Site into computers where they live. If an attacker of this sort targets your site, risk becomes high. You’ll never be able to assign an accurate percentage to your risk. You have vulnerabilities you don’t know about.You have attackers you don’t know about or have limited information about. Many companies don’t have a good handle on their assets. Even if your company can assign exact values to your assets, you’ll never get an exact figure for vul- nerabilities or threats. But all is not lost.You can make a best estimate of vulnerabilities and threats, and along with information about your assets, you can make a judgment about your risk. As new information becomes available, you adjust your risk value. For example, if a new remote root vulnerability is announced in a software package you run, until the time you can get the patch in place, your risk is high. Let’s take a look at some possible ways to measure each of these factors. Determining Your Assets Your company or project has assets, things that have value to you—they either have value to you because they are present, or because you would be damaged in some way if they were lost or disclosed (an asset either makes you money, or you lose money if you lose the asset). As you’ll see, an asset need not be money, literally. Here are some examples of assets: ■ Money and financial information ■ Customer information ■ Products ■ Intellectual property ■ Employees ■ Reputation www.syngress.com 134_ecomm_07 6/19/01 12:02 PM Page 390 Hacking Your Own Site • Chapter 7 391 Someone within the company ought to be concerned with all of these assets. Most information security professionals are only concerned with a subset of these. From the above list, this may include financial information, customer information, products (if your company sells things on the Web), intellectual property, and reputation. Did you know that you kept your reputation on the Web server? If you’re an e-tailer, and you suffer a Web defacement or credit card database theft, then your attacker just removed your customer confi- dence from your Web server. Your job within the security team is to try to reduce the number of exposed assets as much as possible—weighed against business needs, of course. Ideally, you won’t have a reason to have any of your private financial information out on your demilitarized zone (DMZ). However, some companies have a need to share that sort of thing with partners via a private section of their Web site. One type of information that nearly all e-commerce Web sites must maintain is customer information, things such as names, addresses, order history, and credit card numbers.The credit card number data is one of the more worrisome pieces.We’ve all heard horror stories about hun- dreds of thousands of credit card numbers being stolen from e-com- merce databases. Perhaps you’ve even had to get a new card or experienced some fraud due to such an intrusion. If you have some sort of for-pay downloadable product on your Web site, you will want to protect that as much as possible.You may have some intellectual property on your Web servers. Perhaps you have some code to issue license keys that is proprietary. Perhaps your business logic in embedded in your database. The rule of thumb for minimizing assets is this: Don’t have anything exposed that doesn’t absolutely need to be. It’s obvious but often over- looked. Chapter 5 discusses secure site design, and Chapter 6 has infor- mation on ways to deal with credit card information. Refer to these chapters for more help in these areas. www.syngress.com 134_ecomm_07 6/19/01 12:02 PM Page 391 392 Chapter 7 • Hacking Your Own Site Why Attackers Might Threaten Your Site and How to Find Them We know an attacker is one type of threat; others include power out- ages, loss of connectivity, or anything that will impede your ability to do business securely. Chapter 9 discusses availability issues, so in this chapter we focus on attackers. Two main types of threats you might receive are an attack of conve- nience and a targeted attack. An attack of convenience occurs when the attacker has some new exploit that they want to try on every machine in the world, which includes yours. So, although they are scanning the whole Internet looking for vulnerable machines, they scan yours on the way through.The vast majority of the time, these types of scans are for older, known holes. If you keep any kind of minimal vigilance about your patches, you should be pretty safe from this type of attack. A targeted attack is one aimed specifically at you. Usually, such an attacker will take a little time to research your site before blindly firing attacks at you. An attacker that is specifically targeting you is more dangerous. They will be more persistent, they will generally be more intelligent about which attacks they try, and they may even spend the time to do some original research about problems with the software you use to run your site. Your job is to watch for these attackers and to determine what kinds you have coming after you, which is not an easy task.You have very lim- ited information, and you’re trying to determine the intentions of an attacker who may be thousands of miles away, whom you’ve never met. As hopeless as it sounds, you still have a little bit of information to go on. An attack of convenience is usually looking for a limited set of vul- nerabilities.Worms are a good example of this. At the time of this writing, the Ramen worm is making the rounds.The Ramen worm scans hosts for ports 111 (portmapper), 21 (ftp), and 515 (lpd/lprng). It has rpc.statd and wuftpd exploits that work on Red Hat 6.2, and a lprng exploit that works on Red Hat 7.0.You might have slightly different www.syngress.com 134_ecomm_07 6/19/01 12:02 PM Page 392 Hacking Your Own Site • Chapter 7 393 versions of the same software, and it may even have the same vulnerabil- ities, however the automated exploit won’t necessarily work as offsets may be different in your situation. An attacker (or a worm) with an exploit of this type will try it out on you, and if it doesn’t work, she’ll typically just move along to the next IP address. She isn’t interested in you per se, just any machine that will fall for this exact exploit—or perhaps 100 machines. An attacker targeting you would likely try some variations on the same theme, trying to break into your server. He may make adjustments to the exploit, or just move on, having already determined that it doesn’t apply to you. An attacker targeting your site will also usually do some reconnais- sance, usually involving port scanning, OS fingerprinting, and perhaps some simple exploit attempts in order to gauge your level of defense and perhaps grabbing some file samples. By carefully watching firewall and IDS logs—you will begin to understand the difference between someone who has tried their trick and moved on and someone who is sticking around for a little while. You may manage to spot an attacker that looks like he is taking some care to stay below the radar, perhaps by doing a slow scan. Hopefully, the attacker will come from a consistent set of IP addresses, but that may not always be the case. Many times, however, you will often have multiple attackers at a time, which complicates matters further. As a general rule of thumb, you will need to stay informed about the commonly scanned ports for new exploits.You can learn this type of information by reading the Bugtraq and Incidents mailing lists, among others. After you’ve developed a list of things you commonly get scanned for—the noise, essentially—you can focus on the other attacks you receive. www.syngress.com 134_ecomm_07 6/19/01 12:02 PM Page 393 394 Chapter 7 • Hacking Your Own Site www.syngress.com Gauge Your Threat Level with a Honeypot A honeypot (in an information security context) is a system that is designed to be broken into. Setting up a honeypot will give you an opportunity to study tactics of attackers and possibly pick up a new attack or two along the way. Naturally, the attacker shouldn’t be aware that he has broken into a honeypot, and he should think that he’s gotten into an ordinary machine with no special moni- toring. In fact, a honeypot machine typically has extensive moni- toring in place around it, either on the machine itself or via the network. In order for the honeypot to be effective, as much infor- mation as possible must be collected about the attacker. It’s also important that the honeypot machine not be able to act as a client on the Internet in general. You don’t want to have to explain your honeypot project to law enforcement when they show up wanting to know why your machine was breaking into other people’s machines. To avoid this, honeypots are usually placed behind an inverse firewall of sorts; connections get in, but they don’t get out. This may tip off an attacker somewhat, but it’s better than the alternative. It’s also part of your signaling mechanism that something interesting has happened on your honeypot. When your honeypot machine, which normally does nothing on the network, suddenly starts trying to get out to the Internet, then chances are good that someone got in. Even if the attacker figures out that he’s been duped, you have already collected some information. Note that some people decide that a particular machine is a honeypot after it’s already been broken into, that is, after they detected the intrusion on their regular machine, they decided to keep the attacker around to keep an eye on him. I don’t recom- mend this, as it’s never much fun trying to track an attacker without being prepared ahead of time, but it’s an option. For some entertaining examples of people who have decided to take Tools & Traps… Continued 134_ecomm_07 6/19/01 12:02 PM Page 394 Hacking Your Own Site • Chapter 7 395 Testing Your Own Site for Vulnerabilities After you’ve made your best effort to determine what your assets are and have tried to determine what your current threat level is, it’s time to actively audit and assess your vulnerabilities. Before we get to the technical items, let’s discuss a bit some of the factors that affect your decisions on exactly how to perform your vul- nerability audit (also called a penetration test).The most obvious factor is budget. Can you hire people for this purpose? Can you train people you www.syngress.com this route, take a look at the book “Cuckoo’s Egg: Tracking a Spy Through the Maze of Computer Espionage” by Clifford Stoll (Pocket Books), and “An Evening with Berferd” by Bill Cheswick, Steve Bellovin, Diana D’Angelo, and Paul Glick at www.all.net/ books/berferd/berferd.html. Honeypots can be a part of your mechanism for determining your threat level. Some folks are of the opinion that trapping an attacker to study his techniques will give you some advance notice. It’s true that an attacker that is targeting your site will often spend some time on the first machine he can break into (your honeypot should be the easiest machine to penetrate on your network.) My opinion is that little has been formalized in terms of using honey- pots in order to gauge attackers. However, little in the world of trying to determine your threat level has been formalized, so it may very well be a valid technique. One has to have some famil- iarity with forensic techniques, log analysis, and protocol analysis to make a honeypot useful, but help is available in those areas if you’re a beginner. Honeypots serve other useful functions besides determining threat levels. A community of people running honeypots can often provide each other with information about new exploits and worms. For one of the best examples of a community of honeypot opera- tors, check out the Honeynet project (http://project.honeynet.org/). 134_ecomm_07 6/19/01 12:02 PM Page 395 396 Chapter 7 • Hacking Your Own Site have? Can you afford the time, the tools, and equipment? As with most IT functions, you can trade man-hours for capital (or vice versa) when testing for vulnerabilities. Another factor that affects cost is how often you conduct your audit. A penetration test isn’t something you can have done just once.Things change over time, whether the state-of-the-art tools in security and pen- etration have changed, or whether new systems have been added to your site, upgrades to software or configuration changes have been made. Even an experienced security administrator will make mistakes, perhaps forgetting to turn off a change intended to be only temporary. For all of these reasons, you need to recheck your level of vulnera- bility every so often. How often you do is again probably a matter of resources, though checking too often may be disruptive depending on what type of IDS setup you have. If you have the luxury of dedicated staff to do the security assessment, you might check as often as once a month. Limited resources may dictate that you only do a full test once per year, though the idea of going a year without some level of security confidence is a bit frightening. A good change control process can help with minimizing the risks in between full scans. Each time some change is made, make a best effort to determine exactly what will be affected and recheck just those things that are affected.This is harder than it sounds, because it requires a fair amount of discipline on the part of the people making changes to accu- rately record and assess any changes they make and to report the changes to the people who will need to recheck. Some host-based IDS systems will help enforce this, because they will catch some of the changes, but they will never be as effective as accurate records from the people actu- ally making the changes in the first place.You can think of these as incremental penetration tests, similar to doing incremental backups in between full backups. Determining the Test Technique You might briefly consider what type of attacker you want to play against your own site, whether opportunistic or targeted.You could take all the exploit code you can download, compile it up, and throw it at your site. As www.syngress.com 134_ecomm_07 6/19/01 12:02 PM Page 396 Hacking Your Own Site • Chapter 7 397 discussed before, though, not all exploits will work as-is.This could easily result in false negatives, reporting that a service isn’t vulnerable when it is. Of course, any tool or testing method could potentially result in false neg- atives, but blindly running exploits will result in a much higher false nega- tive rate. Frankly, the vast majority of attacks of convenience attempt to take advantage of well-known holes, for which patches have been available for some time. If you’re getting caught by attacks of convenience, then you need to take a hard look at your procedures for tracking new vulnerabili- ties and applying vendor patches. In almost every case, you should be performing the most intelligent attack possible.You should take advantage of your special knowledge of your site setup, short of actual secrets such as password and crypto keys.The types of knowledge you should take advantage of include the following: ■ Trust relationships ■ IP addresses on all network segments ■ Brands and versions of all your software ■ The type of network gear you use ■ Source code for all the software if available (especially custom software) The reason that all of this leverage should be used is that you have to assume that an outside attacker will eventually be able to determine or infer the same information. In most cases, tools are available to probe for this sort of thing.The free program nmap, for example, will allow an attacker to pretty effectively determine OS versions (welook at how to use nmap in the next section). The attitude behind the assumption that an attacker can determine the above types of knowledge is embodied in the phrase “security through obscurity doesn’t work.” Ultimately, all security relies on some sort of “obscurity.” However, you want your security to be reliant on something really obscure, such as a good password or a 128-bit crypto key—not the fact that you’re running a Web server on port 81 (which will be determined rather quickly.) www.syngress.com 134_ecomm_07 6/19/01 12:02 PM Page 397 [...]... (The 3 078 ports scanned but not shown below are in state: filtered) Port State Service 22/tcp open ssh 53/tcp closed domain 53/udp open domain www.syngress.com 134 _ecomm_ 07 6/19/01 12:02 PM Page 401 Hacking Your Own Site • Chapter 7 113/tcp closed auth TCP Sequence Prediction: Class=random positive increments Difficulty=42998 (Worthy challenge) Sequence numbers: 76 B1034E 76 B8D898 76 BEE1B2 76 C50F02 76 CC2ED6... easy problems first, so that you get the most for your money from the external auditing team If they can’t spot any easy problems right off, they will have to work a bit harder and be more thorough www.syngress.com 4 17 134 _ecomm_ 07 418 6/19/01 12:02 PM Page 418 Chapter 7 • Hacking Your Own Site Summary The goal in attacking your site is to assess how good your security design is and how well it has been... network, so there are no holes there that we know of www.syngress.com 413 134 _ecomm_ 07 414 6/19/01 12:02 PM Page 414 Chapter 7 • Hacking Your Own Site The rest of the items that it flagged are innocuous.There is an example shown in Figure 7. 3 Figure 7. 3 Nessus “Orange” Warnings Here Nessus has recommended that you configure your Web server to lie about what software it is (this one already does, as you... DMZ segments to find out what happens when your firewall is breached .Your www.syngress.com 134 _ecomm_ 07 6/19/01 12:02 PM Page 4 17 Hacking Your Own Site • Chapter 7 security design ideally ought to be failsafe in layers Even if the firewall wasn’t there, or was misconfigured, would you still be safe? If an attacker somehow managed to get control of a machine on your financials DMZ segment, what would that... from server www.syngress.com 134 _ecomm_ 07 6/19/01 12:02 PM Page 403 Hacking Your Own Site • Chapter 7 *** Default servers are not available In this case, we didn’t get an answer, so this is no help Here’s what it looks like when it works correctly: [root@ns1 /root]# nslookup -q=txt -class=CHAOS version.bind 2 07. 126.1 27. 66 Server: Address: www1.securityfocus.com 2 07. 126.1 27. 66 VERSION.BIND text = "8.2.3-REL"... www.syngress.com 134 _ecomm_ 07 6/19/01 12:02 PM Page 399 Hacking Your Own Site • Chapter 7 ahead and do this After (or if) your defense team has made the determination that an attacker is out there, go ahead and share the information about the penetration test taking place and turn off the stealth techniques to avoid spending unnecessary cycles Researching Your Vulnerabilities Your first step is to do... 21/tcp open ftp 23/tcp open telnet 79 /tcp open finger 80/tcp open http 98/tcp open linuxconf 113/tcp open auth 513/tcp open login 514/tcp open shell 1024/tcp open kdm 5680/tcp open canna www.syngress.com 134 _ecomm_ 07 6/19/01 12:02 PM Page 405 Hacking Your Own Site • Chapter 7 66 67/ tcp open irc TCP Sequence Prediction: Class=random positive increments Difficulty=32 670 68 (Good luck!) Remote operating system... “Security check.”This example took a couple of hours to complete Figure 7. 1 Status Screen during Scanning www.syngress.com 134 _ecomm_ 07 6/19/01 12:02 PM Page 413 Hacking Your Own Site • Chapter 7 After the scan is complete, a screen is displayed showing the IP addresses scanned, and any vulnerabilities or warnings found (see Figure 7. 2) Figure 7. 2 Nessus Report Screen This Nessus interface is somewhat typical... to get rid of any easy problems first so that you get the most for your money from the external auditing team www.syngress.com 134 _ecomm_ 07 6/19/01 12:02 PM Page 423 Hacking Your Own Site • Chapter 7 Frequently Asked Questions The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to... include some simple graphs Hiring a Penetration Testing Team Should you have an internal team or an external team doing your penetration test? As usual, the answer depends a great deal on your resources www.syngress.com 134 _ecomm_ 07 6/19/01 12:02 PM Page 415 Hacking Your Own Site • Chapter 7 You can hire any number of individuals or teams to perform a penetration test of whatever scope you like In an ideal . Traps… Continued 134 _ecomm_ 07 6/19/01 12:02 PM Page 394 Hacking Your Own Site • Chapter 7 395 Testing Your Own Site for Vulnerabilities After you’ve made your best effort to determine what your assets. break www.syngress.com 134 _ecomm_ 07 6/19/01 12:02 PM Page 389 390 Chapter 7 • Hacking Your Own Site into computers where they live. If an attacker of this sort targets your site, risk becomes high. You’ll. determined rather quickly.) www.syngress.com 134 _ecomm_ 07 6/19/01 12:02 PM Page 3 97 398 Chapter 7 • Hacking Your Own Site So, it makes sense to give your invited attackers, whomever they may be,