Attack Profiles

Attack Profiles Overview This book discusses a number of potential attacks without necessarily defining them This chapter profiles all of the common attacks hackers use to localize, identify, and attack your systems Given the information about how these attacks work, you can configure sophisticated firewall logging and alerting mechanisms to detect them This chapter is broken down into the following broad categories: Denial−of−service attacks Exploitation attacks Information gathering attacks Disinformation attacks These broad categories describe the purposes of nearly all hacking attacks Denial−of−Service Attacks Denial−of−service attacks attempt to prevent you from providing a service by crashing or overwhelming your service computers Denial−of−service attacks are the easiest hacks to attempt, so they are quite common This section lists the most common of these attacks: Ping of Death Teardrop UDP floods SYN floods Land Smurf Fraggle E−mail bombs Malformed Messages Ping of Death The Ping of Death is the granddaddy of all denial−of−service attacks It exploits the fact that many TCP/IP implementations trust that ICMP packets are correctly formed and perform too little error checking Warning Attack Status: The original Ping of Death is obsolete; undiscovered effective malformations of the ICMP echo request may exist, however Also, many other SMB, RPC, TCP, IP, or ICMP malformation attacks called "nukers" perform similar functions Profile In order to test the throughput capabilities and packet size restrictions, ICMP packets can be created having anywhere up to 64KB This allows you to determine the actual maximum packet size between you and a target system on the Internet In the early days of the Internet, this functionality was important because many routers had maximum packet size restrictions In large ping packets, 240 the payload portion of the packet is filled with meaningless data The maximum payload size is 216 (minus packet data overhead) Ping−of−Death attacks are propagated by creating a malformed ICMP echo request packet in which the claimed packet size exceeds the maximum possible size Because the payload size indicator is 16 bits, yielding a maximum possible packet size of 65,535 bytes (the actual limit is around 65,500 bytes due to packet header data overhead), packets that claim to be larger than 65,500 bytes can cause TCP/IP errors in the receiving system In a typical TCP/IP implementation, when a packet header is read, the information contained in the header is relied upon to create a buffer for the payload When the claimed size of the packet header plus payload exceeds the 64KB maximum defined by the TCP/IP specification, the TCP/IP implementation may crash due to memory allocation errors Defense All standard TCP/IP implementations have been hardened against oversize packets, and most firewalls automatically filter these attacks Windows versions since Windows 98, Windows NT since Service Pack 3, Linux, Solaris, and the Mac OS are all immune to standard variations of the Ping of Death Configuring firewalls to block ICMP and any unknown protocols will prevent this attack For this reason, this attack in its current form is already obsolete and has no real future Teardrop Teardrop attacks exploit a potential weakness in the fragment reassembly process of some TCP/IP implementations Warning Attack Status: TCP/IP implementations can easily be hardened against Teardrop, but many operating systems are still vulnerable to it Profile A teardrop attack exploits implementations that trust information in the packet headers of IP fragments IP fragments contain fields that indicate which portions of the original packet the fragment contains Some TCP/IP implementations (including Windows NT until Service Pack 4) will crash when presented with forged fragments that have overlapping offsets Defense Apply the latest patches, service packs and hotfixes for your operating system If you run Windows NT and must remain on Service Pack 3, apply the teardrop hotfix For other operating systems, check with your vendor for a patch to this problem Configure firewalls to reassemble fragments rather than forwarding them; most firewall TCP/IP implementations should be hardened against this attack UDP Floods Various spoofing attacks exploit simple TCP/IP services like Chargen and Echo to transmit useless bandwidth wasting data Warning Attack Status: These attacks are most easily defended against by not running the unnecessary services they exploit 241 Profile UDP floods are extremely simple: By forging a UDP connection to the Chargen service running on one host that has the reply address of a host running the Echo service, a hacker can create a useless stream of data flowing between the two hosts Creating enough of these streams causes a bandwidth denial of service Defense Configure hosts to disable simple TCP/IP services that are not necessary Configure routers to block UDP requests from the Internet to these services SYN Floods SYN floods are simple attacks that exploit the connection mechanism of TCP Warning Attack Status: SYN Floods are easily defended against, but watch out for future variants Profile The requesting client transmits a SYN message to the host service requesting service, and the receiving server responds with a SYN−ACK message accepting the connection The client then responds with an ACK message, after which traffic can flow over the established bidirectional TCP connection When a server receives the initial SYN message, it typically creates a new process thread to handle the client connection requests This process thread creation requires CPU compute time and allocates a certain amount of memory When the TCP session is closed or after a fairly long time−out period, the server closes the TCP session which releases the memory used The amount of memory and compute time therefore determines the number of simultaneous sessions a server can support SYN floods are bogus SYN messages sent to servers How a SYN flood affects a victim computer depends upon its implementation of TCP/IP Some TCP/IP stack implementations are only capable of waiting for ACK messages from a limited number of computers because they have a limited memory buffer for connection establishments If this buffer is filled with bogus connection initiations, the server will cease responding to further connection attempts until the attempts in the buffer time out In implementations that are not connection−establishment limited, SYN floods have a similar effect Since the server doesn't know a legitimate SYN message from a bogus message, it allocates compute and memory resources to establishing a connection By flooding the server with a large volume of requests, the server's maximum capacity can be used by these bogus and useless connection attempts Defense The only defense against SYN floods is a good firewall that can recognize the characteristics of a SYN flood—numerous identical connection attempts coming from the same IP address These firewalls can filter subsequent connections from the same host, thus eliminating these SYN floods 242 Since the SYN flood source machine isn't looking for a response, there's no reason why the SYN flood attack software can't simply use randomly generated IP addresses in the source field This sort of SYN flood can not be discerned from a simple high volume of traffic and is able to get past SYN flood filters Land Attack The Land attack is a variation of the SYN flood that can cause unhardened TCP/IP implementations to "chase their tails" in a never−ending connection−establishment loop Warning Attack Status: Land attack is already obsolete and easily defended against Profile In the Land attack, a specially crafted SYN packet is transmitted to a server host Both the source and destination addresses of the SYN packet are set to the server's IP address This causes the recipient server to SYN−ACK to its own address, which it subsequently ACKs and establishes an empty connection Each connection will remain until the server operating system times out the connection due to inactivity Various operating systems respond to the Land attack differently—Windows NT becomes extremely slow for about five minutes Many Unix implementations crash Most vendors have supplied a fix for the Land attack Defense Apply Land attack patches, hotfixes, or the latest service packs Configure firewalls to drop any packets that have an internal source address inbound on the external interface This always indicates a spoofed address, and dropping these packets should be default policy in every firewall The following IP addresses are illegal on the Internet and should always be filtered in or out of your external interface: 10 domain 127 domain 192.168 domain 172.16 through 172.31 domain In addition, you should filter your own assigned IP addresses Smurf Attack The Smurf attack is an extremely effective denial−of−service attack based on the direct broadcast addressing feature of IP that allows a host to transmit data to all hosts in its subnet Warning Attack Status: Smurf attacks can be filtered by firewalls, but they may still waste the bandwidth of your Internet connection because Smurf attacks outside your network can affect you Profile A simple Smurf attack proceeds by flooding a victim host with ICMP echo request (ping) packets that have the reply address set to the broadcast address of the victim's network This causes all the hosts in the network to reply to the ICMP echo request, thereby generating even more 243 traffic—typically one to two orders of magnitude more traffic than the initial ping flood A more complex Smurf attack proceeds as above but with the source of the echo request set to a third−party victim, which will receive all the echo requests generated by the targeted subnet of hosts This attack is useful to hackers because they can use a relatively slow link like a modem to cause an avalanche of ping traffic to be sent to any location on the Internet In this way, a hacker with a slower link than his ultimate victim can still flood the ultimate victim's pipe by smurfing a higher speed network than that of the ultimate victim Defense To prevent hackers from exploiting your network to attack others, shut off the broadcast addressing feature of your external router or firewall To prevent being the ultimate victim of a Smurf attack, configure your firewall to drop ICMP ping messages If a high−speed provider (like your ISP) has been successfully smurfed and your network is the victim, there's nothing you can about relieving the congestion that the ICMP traffic will cause, even if you filter it out on your end Contact your ISP about their firewall policy if this is a concern Note Check out http://www.powertech.no/smurf to determine if your ISP is vulnerable to Smurf attacks Fraggle Attack The Fraggle attack is a simple modification of the Smurf attack, which uses UDP echo messages rather than ICMP Warning Attack Status: Like its sibling the Smurf, the Fraggle attack can be filtered but may still consume network bandwidth in areas outside your control Profile Fraggle is a simple rewrite of the Smurf attack that uses UDP rather than ICMP This allows the attack to pass through firewalls that only filter ICMP Defense Filter out UDP Echo messages at the firewall E−mail Bombs Hackers can flood an e−mail server by repeatedly sending the same large e−mail file to your e−mail server Warning Attack Status: E−mail bombing and its relative, spamming, are fairly easy to filter, but they waste bandwidth outside your zone of control Profile E−mail bombs are one of the oldest annoyance attacks around By setting up a machine to constantly transmit e−mail to the same address, the attacker can use up bandwidth on the receiver's network 244 This attack isn't all that serious, considering the fact that it requires nearly as much bandwidth on the transmitter's end as it does on the receiver's, which makes true denial of service difficult E−mail bombs are also easy to trace, unless they've been transmitted through a mail host that strips headers Defense Configure mail hosts to automatically delete excessive or duplicate messages from the same host Malformed Message Attacks Many services on various operating systems will crash if they receive malformed messages because the services not adequately check for errors in messages before processing them Warning Attack Status: Malformed message attacks will always be around The number and variety of them makes it impossible to make general statements about vulnerability Profile All operating systems have susceptibilities (known or unknown) to various message malformation problems Variations include: E−mail buffer overruns from malformed e−mail messages Web services that can be exploited by providing exceptionally long URLs Crashing RPC services by transmitting random data to them Defense Stay up−to−date on the latest vulnerabilities reported by your software vendor Apply patches and hotfixes to production machines as soon as you're certain that they are stable Exploitation Attacks Exploitation attacks are those attacks that attempt to take direct control of a machine Here's a list of some of the most common: TCP/IP connection hijacking Layer−2 connection hijacking Password guessing Trojan horses Buffer overruns TCP/IP Connection Hijacking TCP/IP connection hijacking exploits the fundamental non−randomness of TCP sequence generation algorithms to insert packets into an existing TCP/IP connection in order to "hijack" the connection Warning Attack Status: This attack is hibernating Once common because simple pseudorandom 245 number generators were used to create sequence numbers, most modern TCP/IP stacks now have highly sophisticated sequence number generators However, they are not yet truly random, so there's no reason to believe that an as−yet unknown algorithm can't make this attack common again Profile TCP streams use pseudo−randomly generated sequence numbers to order TCP packets and ensure that the stream is reconstructed in the correct order at the remote end If a hacker can predict the next correct sequence number, she can insert her own packets that will be received as if they were the correct packets Subsequent packets from the original host will be discarded as spurious retransmissions or denial−of−service attacks that should be dropped The problem is in predicting the next correct sequence number The difficulty in determining the next valid sequence number depends entirely upon the quality of the pseudorandom number generation (PRNG) algorithm used by the host computer to generate the sequence numbers for the TCP stack Computers are terrible at generating random numbers; the same code run twice on any two computers will always generate the same set of numbers Therefore, PRNGs must rely on some external data as a source for "randomness." Early on, some PRNGs used sources as simple as the real−time clock as external data, but this source isn't at all random and is easily predicted Better sources include timings between keystrokes or the frequency of other I/O operations, but these only work well on computers that have humans using them Without the human element, these operations are all just as predictably ordered as anything else in a computer So, for devices, there is no truly "good" source of random numbers for TCP sequence generation RFC 1948 suggests using the host's IP address and the source and destination ports along with a fixed truly random "key" number stored on the host to generate random numbers As long as this key remains secret, this mechanism should be sufficient to ensure random sequence numbers Should be The remaining problem is that no matter how random the initial number is, subsequent numbers are generated by a PRNG All PRNGs, no matter how random the sequence "looks," contain predilections toward certain sequences (this predilection is called strange attraction, meaning that for some strange reason, the numbers are attracted to a certain order) These strange attractors can be graphed visually in two or three dimensions to show their non−randomness While predicting the next random number is still very difficult, predicting a large set of numbers of which one might be the next random number is relatively easy And if you remember that the remote host will simply drop "wrong" sequence numbers, the hacker can push a very large set of guesses at the remote host and need only hit on one to hijack the stream Considering that a hacker could easily push 5,000 guesses down the pipe without straining the connection on a standard T1, it's conceivable that the entire set of likely sequence numbers could be used to subvert the connection Again, this depends upon the quality of the PRNG Note TCP sequence prediction is how Kevin Mitnick (see http://www.2600.com/) performed many of his most famous hacks So how likely is it that your devices and computers could be exploited by a TCP hijacking attempt? Linux uses a very good PRNG, which makes sequence number generation highly unlikely OpenBSD 2.9 has a PRNG that makes prediction impossible, but there's a slight chance that a hacker could predict sequence numbers in OpenBSD 2.8 or below Windows 2000, IRIX, Mac OS X, and NT4 SP6a are somewhat susceptible to sequence number prediction, and NT4 SP3, 246 Windows 9x/Me, Mac OS 9, most commercial variants of Unix, and nearly every network device are so flawed that a competent hacker would be able to predict sequence numbers Tip http://razor.bindview.com/publish/papers/tcpseq.html has an excellent and practical analysis of sequence number prediction for major operating systems Defense You can use a socket redirector (such as redir, available for various versions of UNIX) and a host OS that is invulnerable to prediction (such as OpenBSD 2.9 or Linux) to redirect all TCP streams (even if you use a 1:1 redirection) before they go to your network assets Redirectors receive and then regenerate TCP streams—they are generic proxies and work with any protocol that can be NATed NATs won't defend against this attack because they don't actually regenerate the sequence numbers Other than that, it's not possible to defend against this sort of attack Once a PRNG has been reduced and encoded into an attack script, it's up to the original system vendor to patch the PRNG to provide increased randomness in its sequence numbers Layer−2 Connection Hijacking Layer−2 connection hijacking exploits the nature of Layer−2 switches to perform a man−in−the−middle attack Warning Attack Status: Layer−2 connection hijacking is brand new and as−yet uncommon It requires Layer access to the network, which would be difficult in all but one circumstance: collocation at an ISP facility Profile Layer−2 connection hijacking is a nifty little exploit that exploits assumptions that were made about the Ethernet ARP protocol that have since changed in the evolution of Ethernet ARP, Address Resolution Protocol, is used to map Ethernet MAC addresses to IP addresses When a host comes online, it makes IP broadcasts to all hosts that cache the computer's MAC address so that other hosts can record the MAC address in their individual ARP tables and thus direct Ethernet packets to a specific host, given that hosts IP address Duplicate IP addresses that would be used by a hacker to spoof an IP address are detected by the host that "owns" an IP address If it sees a broadcast from another machine on the network that claims its IP address with another MAC address, it will complain, and the new host will be denied in the ARP tables of the receiving hosts In a standard Ethernet broadcast environment, this works perfectly well Switches improve bandwidth utilization by routing traffic directly between the two MAC addresses involved in the conversation, rather than "broadcasting" the conversation to everyone Switches maintain a MAC address table to determine which hosts are on which physical ports But they don't track IP information because switches are not specific to IP; they can transport any Layer−3 networking protocol This means that a multitude of hosts can communicate simultaneously through a switch without colliding with one another This works extremely well—so well that switches have replaced hubs in most environments 247 Enter the Layer−2 connection hijacking problem When a host, say a web server, boots, it broadcasts its IP address and MAC address in an ARP packet to all hosts on the subnet, but most importantly to the default gateway Enter the hacker's machine, which floods the MAC address of the default gateway with newer ARP packets that claim that the hacker's computer is the owner of the IP address But because these packets aren't broadcast to all hosts on the switch, the original owner never hears them and so doesn't complain The default gateway, assuming that a complaint would originate if the changed MAC address were illegitimate, records the new MAC address as the correct one for the web server's IP address At this point, all traffic bound for the web server will now be transmitted to the MAC address of the hacker's computer The hacker, having the original ARP request of the web server, knows its MAC address When it receives packets destined for the web server, it simply retransmits them to the web server's MAC address Since this goes through the switch, no computers hear this connection except the hacker's computer and the web server At this point, the hacker's computer has become a "bridge" between the default gateway and the web server, and is now able to monitor all data flowing between the two machines, including cryptographic key exchanges From this point on, all information flowing between the web server and its default gateway is subject to whatever monitoring and reconstruction the hacker's computer is capable of performing Linux is capable of performing all the Layer−2 bridging required for this exploit This exploit requires Layer−2 access to the network, so it's unlikely except in one environment: ISP Collocation If you collocate machines at an ISP's facilities, your computers are connected to the same switch as potentially hundreds of other clients Any of these clients could perpetrate this attack against your systems and monitor your data While a hacker isn't likely to sign up for collocation service, they could easily use a different exploit to gain control of someone else's collocated server to then perform this exploit on yours Any government or corporate interest with means and loose ethics could perpetrate this as well Defense To defend against this attack, use hubs rather than switches between any of your public computers at a collocation facility Or require that your ISP use Layer−3 routers rather than Layer−2 switches for connectivity Considering that many network load balancers work better with hubs as well, you might consider making this your standard policy Password Guessing Once a hacker has identified a host and found exploitable user account based services like NetBIOS, Telnet, or NFS, a successful password guess will provide control of the machine Warning Attack Status: Password guessing attacks are quite common, but are usually easily defended against Watch out for remote control software like VNC or pcAnywhere that may be susceptible to high−speed automated attacks Profile Most services are protected with account name and password combinations as their last line of defense When a hacker finds an exploitable service running on a target machine, the hacker must still provide a valid account name and password in order to log in Automated password guessing software uses lists of common passwords, names, and words from the dictionary to attempt to guess high profile or important account names, such as the root user 248 password on Unix systems or the Administrator account on NT systems The software typically takes a list of account names and a list of possible passwords to try and simply tries each account name with each password Hackers are using new "common password" lists to make these attacks faster These lists are derived from the statistical analysis of stolen account information from exploited servers By combining lists of stolen passwords and analyzing the lists for password frequency, hackers have created lists of passwords in order of how commonly they are used This means that if any accounts on your network have relatively common passwords, hackers will get in, and quickly We've used these lists to gain administrative access to servers in as little as 11 seconds over the Internet Defense Use passwords that are difficult to guess, such as combinations of words and punctuation Make sure exploitable services like NFS, NetBIOS, and Telnet are not exposed to the public Establish lockout policies if the service supports it Trojan Horses Hackers install software on exploited computers to further gain control of a system Warning Attack Status: Trojan horses remain an extremely dangerous, though difficult to accomplish, form of attack However, many new worms and e−mail viruses exploit other vectors to get in and then use embedded Trojan horses to connect back out Profile Trojan horses are programs that are surreptitiously installed on a target system either directly by a hacker, by a computer virus or worm, or by an unsuspecting user Once installed, the Trojan horse either returns information to the hacker or provides direct access to the computer The most useful sorts of Trojan horses are called backdoors These programs provide a mechanism whereby the hacker can control the machine directly Examples include maliciously designed programs like NetBus, BackOrifice, and BO2K, as well as benign programs that can be exploited to give control of a system like netcat, VNC, and pcAnywhere Ideal backdoors are small and quickly installable, and they run transparently The term "Trojan horse" doesn't apply to a specific type of software, it applies to how the software is used There's nothing special about NetBus or BackOrifice that officially makes them Trojan horses, other than their typical use They are just network−connected command prompt programs, the same way that VNC and pcAnywhere are network−connected GUI programs The term Trojan horse applies to how the software is used, not why it was produced Self−propagating Trojan horses are called worms Defense Strip executable attachments from e−mail and avoid downloading untrusted software Use network scanning software to constantly monitor listening TCP services on interior hosts—this will expose many known Trojan horses Use proxy filters that block unknown protocols at the border 249 Buffer Overruns Buffer overruns are a class of attacks that exploit a specific weakness common in software Warning Attack Status: New buffer−overrun attacks are found all the time IIS has been hit with so many new buffer overrun attacks in 2001 that many corporations are moving away from it as a service platform Automated worms that exploit common IIS buffer overruns have swamped the net with scanning and copying activity as they search for victims and propagate Profile Buffer overruns exploit the fact that most software allocates blocks of memory in fixed−size chunks to create a scratchpad area called a buffer, within which it processes inbound network information Often these buffers are programmed to a fixed maximum size, or they are programmed to trust the message to correctly indicate its size Buffer overruns are caused when a message lies about its size or is deliberately longer than the allowed maximum length For example, if a message says it's 240 bytes long, but it's actually 256 bytes long, the receiving service may allocate a buffer only 240 bytes long but then copy 256 bytes of information into that buffer The 16 bytes of memory beyond the end of the buffer will be overwritten with whatever the last 16 bytes of the message contains Hackers exploit these problems by including machine language code in the section of the message that is past the buffer end Even more disturbing is the fact that software is often written in such a way that code execution begins after the end of the buffer location, thus allowing hackers to execute code in the security context of the running service By writing a short exploit to open a further security hole and postfixing that code to the buffer payload, hackers can gain control of the system Defense Buffer overrun attacks are common and crop up all the time Defend against them on public servers by staying up−to−date on the latest security bulletins for your operating system, or by using security proxies that can drop suspicious or malformed connections before they reach your server Information Gathering Attacks Information gathering attacks are not exploits or denial−of−service attacks; they themselves nothing harmful to the target These attacks are used to provide information for further intrusion into a system Hackers routinely employ these methods to obtain and identify targets This section covers the following information gathering attacks: Various scanning techniques Architecture probes Exploiting information services Address Scanning Hackers use automated software to transmit ICMP echo messages to a range of target IP 250 addresses Those that respond indicate that they exist Warning Attack Status: Address scanning is a common first sign of attack Hackers often use address scanning and related scanning techniques to find hosts Fortunately, address scanning is easy to filter Profile By using automated software, hackers transmit ICMP echo messages across a very wide range of IP addresses (usually entire subnets) Those computers that respond become targets for further information−gathering attempts Defense Filter out ICMP echo messages at the firewall Port Scanning Hackers use automated software to establish TCP connections to various important ports on servers to determine if hosts exist and which exploitable services they run Warning Attack Status: Port scanning is widely used by hackers to identify targets, but it is easy to detect Profile By using an automated tool, hackers connect to a sequence of TCP ports across a wide range of hosts The scanning software reports those hosts with which it successfully established connections Port scanning is the usual first step in an attack Defense Software that can detect numerous connection attempts from the same host can be used to detect scanning You can also use seduction servers operating on ports normally used by standard TCP/IP services to detect scanning Many firewalls detect scanning and can be configured to automatically block scanning attempts Inverse Mapping Scanning is becoming worthless for hackers since firewalls can filter ICMP echo messages, and scan detectors, or deception services, can detect scanning activity Hackers have figured out how to use packet types that cannot be filtered to infer information about the interior of a network Warning Attack Status: Inverse mapping attacks are easy to filter out Profile Inverse mapping works by inferring information from ICMP router replies Hackers can infer which hosts exist by the lack of an ICMP "host unreachable" message when they transmit bogus response messages to hosts These responses generate no reply from the host, but they also generate no error from the forwarding router Those hosts for which no "host unreachable" messages are returned obviously exist This information attack is a response to scan detectors 251 Since normal scanning activity is easily detected by firewalls, hackers use common message types that firewalls cannot be configured to trigger on These message types include: RESET messages SYN−ACK messages, which would come from legitimate connection attempts to public servers from internal clients and are, therefore, extremely common DNS response packets, which are replies to messages generated internally Defense Stateful inspectors and true Network Address Translators automatically protect against this exploit, as non−routing proxy servers To be certain, filter ICMP host unreachable replies or configure your firewall to use Stealth mode, which stops replies to ICMP and unsuccessful TCP SYN messages Slow Scanning Port scanning detectors can detect a high rate of similar connections going to numerous ports Solution: slow down the scanning rate Warning Attack Status: This attack is a modification of the port−scanning technique Its utility is dubious considering the time delay it causes Profile Slow scanning methods rely upon the fact that firewalls and scan−detection software expect to see a high rate of connections from a single address to determine whether or not a scan is occurring Scan detectors detect high rates by keeping track of the number of connections a specific host requests in a certain time frame (10 per second, for example) By scanning slower than the timeout rate of scan detectors (one attempt per second, for example), slow scanners avoid detection Unfortunately for hackers, the slow scan inherently takes a long time, so these attacks are only used when specific systems are attacked for a purpose Defense Slow scans are very difficult for scan detectors to find Seduction services are a more appropriate detector since they shouldn't be hit at all for legitimate traffic Architecture Probes Hackers transmit garbled packets to host computers By examining the responses, hackers may be able to determine the operating system running on the target machine Warning Attack Status: Currently rare, these attacks will become increasingly common Profile Hackers examine the responses to bad packet transmissions from a target host using an automated tool that contains a database of known response types Because no typical response definition exists, each operating system responds in a unique manner By comparing unique responses to a database of known responses, hackers can often determine which operating system the target host 252 is running Hackers can also use a simple statistical analysis of the TCP sequence numbers from any connection stream originating on your computer to "fingerprint" the TCP/IP stack on your machine You can even tell which service pack an NT server is running using this method, and it is impossible to prevent others from doing as well Defense Assume hackers can determine which operating systems your public hosts run Plan your defenses such that they not rely upon security through obscurity For example, you shouldn't assume a hacker can't tell you're running Windows NT Server on your machine because you've blocked identifying ports You should still take all security measures to secure an operating system, even if you don't think a hacker knows which operating system it is DNS Zone Transfers Hackers can transfer name information from your DNS server to identify internal hosts Warning Attack Status: This attack does not constitute a denial of service or exploitation itself and is easily defended against Profile The DNS protocol does not perform authentication for transfers or informative updates This makes the protocol exploitable in a number of different ways Hackers can perform a zone transfer to get the names and internal IP addresses of all your hosts in a single operation if you maintain a public DNS server Defense Smaller organizations should not run their own DNS servers Use DNS servers that support split DNS to ensure internal names and addresses remain private Filter zone transfer requests at the firewall Use internal DNS servers not available from the Internet for inside names and separate public DNS servers for public names to prevent this attack and to prevent hackers from querying your DNS server to determine the internal IP ranges used on your network Finger The Finger protocol can provide enough information about users to allow hackers to guess usernames or passwords Finger was commonly employed in the early days of the Internet as a way to lookup e−mail addresses Profile Hackers use the Finger command to probe a Finger server for information about the users of a system Often, account names and even clues that yield passwords can be obtained Defense This common attack made the Finger protocol obsolete Nobody expects to get useful information from it anymore, so simply disable it Block and log Finger connection attempts at your firewall 253 LDAP The Lightweight Directory Access Protocol is yet another information leaking service By providing LDAP information to the public, which might include valuable clues into the nature of your network and its users, you provide a wealth of information to hackers Profile Hackers use the LDAP protocol to glean information about systems inside networks and their users Defense Block and log LDAP probes into your inside network If you provide LDAP services on public machines, allow LDAP into your DMZ Consider a "split LDAP" policy where you provide full LDAP services inside your network but only a limited set of information publicly SNMP Leakage Simple Network Management Protocol was designed to automatically provide the configuration details of network devices As such, "leaky" devices in a DMZ or on the public side of your network can provide a wealth of information about the interior of your network Warning Attack Status: Common, but usually low risk Some devices that can be controlled via SNMP would be especially susceptible Profile Nearly every type of network device, from hubs to switches to routers to servers, can be configured to provide SNMP configuration and management information Interfaces like DSL adapters and cable modems are frequently SNMP configurable, as are many firewalls Because of the ubiquitous nature of SNMP, it is frequently overlooked on devices that exist outside the public firewall, providing a source of information about your network and the possibility that a device could be remotely managed by a hacker An example of this is a common brand of VPN controller that must be placed in parallel with the firewall and which exposes its SNMP information to the public interface so that it can be controlled by the service provider These boxes leak a tremendous amount of information about the structure of the internal network, including all internal IP addresses and MAC addresses This information can tell a hacker exactly how attack the network, such as to source−route through a NAT (an exploit that the same brand of VPN device was vulnerable to until the most recent firmware patch, by the way) Defense Disable SNMP on every device that exists outside your firewall—even if a service provider says they need it It's not their network; it's yours If they refuse to reconfigure the devices, drop their service and go with someone who really understands security Disinformation Attacks Disinformation deceives the attack target to plant incorrect information This information paves the way for future attacks This section identifies three disinformation attacks: 254 DNS cache pollution Registrar usurpation Forged e−mail DNS Cache Pollution Hackers can provide bogus updates to DNS servers with incorrect IP addresses Warning Attack Status: DNS cache pollution is becoming increasingly difficult for hackers to accomplish due to strong security by major ISPs, but it is still not impossible Profile Because DNS servers not perform authentication when exchanging information with other name servers, hackers can insert incorrect information that would divert users to the hacker's own hosts Defense Filter inbound DNS updates at your firewall; no external name server should update your internal server's knowledge of interior machines Firewalls that support split DNS already support this line of defense Registrar Usurpation Internet registries (also called Internet Network Information Centers) form the root of the DNS name system Some registries have reported successfully forged update messages that have allowed hackers to redirect site traffic from the legitimate owners Warning Attack Status: Most registrars have changed their update policies to more carefully guard against these attacks Profile Some Internet name registrars rely on e−mail messages for updates They compare the e−mail address of the registered owner to incoming e−mail addresses containing update messages, and, if they match, the registrar performs the update Because e−mail can be forged, these updates may be illegitimate Defense It is not possible for end users to defend against these attacks Most registrars have enacted more stringent update confirmation mechanisms, including reply−to e−mail and telephone confirmation Forged E−mail Hackers can create e−mail that appears to be coming from anyone and requires a reply In a variation of the attack, they can spoof the reply−to address as well, making the forgery undetectable Warning Attack Status: E−mail forgery is probably the most serious form of attack against your network, and it's extremely difficult to defend against 255 Profile Using techniques as simple as configuring an e−mail client with incorrect information, hackers can forge e−mail to your internal clients By claiming to be from someone the client knows and trusts, this e−mail uses a psychological attack to induce the reader to return useful information or includes an installable Trojan horse or a link to a malicious website SMTP does not authenticate the identity of an e−mail sender, and many versions of e−mail programs not log enough information to properly track the source of an e−mail message E−mail servers normally include a chain of transmission headers in their e−mail messages, but numerous e−mail servers are known to strip these headers Since hackers know which servers strip e−mail headers, they use them to make their attacks anonymous Laundering IP addresses through a poorly configured proxy server can also make e−mail untraceable Tip Reading a list of servers known to strip e−mail headers (called "anonymizers" by hackers) is like reading a Who's Who of the gov (government) domain Why does the government run so many servers that strip headers? So it can keep track of all the machines from which requests to send striped−header e−mail originate Defense The only true defense against e−mail forgery is user awareness; make sure your users understand that e−mail forgery is possible and constitutes a likely attack mechanism in well−defended networks You can use S/MIME enabled e−mail clients and install personal encryption certificates to sign e−mail from all internal users Unsigned e−mail should be considered potentially suspect Filter executable attachments out of e−mail at the firewall Consider using PGP or certificates to authenticate your e−mail Unfortunately, authenticated e−mail hasn't really caught on, so you can't expect to be able to authenticate the e−mail you receive except within your own organization Case Study: As You Sow, So Shall You Reap About a year ago, I visited an old high school friend who had recently become very adept at hacking in his spare time Eager to show off the spoils of his newfound pastime, he pulled up movies, music, and software he'd gotten for free from the Internet Reluctant to moralize, I sat back and took the opportunity to immerse myself in the psyche of an active hacker While we talked and watched the random gyrations of WinAmp (an MP3 music player that creates random psychedelic patterns on the screen that are synchronized to the music), a command−prompt window suddenly popped up We both leaned forward and watched incredulously as the following letters appeared one at a time, as if typed by unseen hands: C:\>Format c: The cursor paused at the end of the command line My friend rushed to his machine and immediately closed the command prompt We expressed shock at what we both knew was a Trojan horse attack, and then I immediately set about to defend and respond Having never actually been present during a successful intrusion, the opportunity excited me tremendously 256 My first step was to issue the netstat −a command We quickly identified an unknown listening service on port 12345 Since I recognized the common listening ports for a Windows computer, I knew this one was unusual I recorded the remote IP address of the computer attached to it The mysterious command window appeared again, so I immediately shut it again I then pulled up a port scanner and scanned the IP address of the remote computer The results of the port scan revealed a listening service on port 135—the sure sign of a Windows NT computer The computer wasn't running other proxy services, so I was comfortable that the hacker hadn't laundered his (I'm assuming the hacker was male) IP address To end the attack, I took a chance that the hacker hadn't updated to the latest service pack and telnetted to his RPC port Typing random data into this port caused a blue−screen denial−of−service attack in early Windows NT service releases Sure enough, a subsequent port scan revealed that the attacker's machine was no longer responding We then set about searching for the Trojan horse program on my friend's computer After some research and looking, we found a copy of the NetBus Trojan horse It had been installed by one of the pieces of pirated software my friend had downloaded from a hacker's website  ... ISP is vulnerable to Smurf attacks Fraggle Attack The Fraggle attack is a simple modification of the Smurf attack, which uses UDP echo messages rather than ICMP Warning Attack Status: Like its sibling... against this attack UDP Floods Various spoofing attacks exploit simple TCP/IP services like Chargen and Echo to transmit useless bandwidth wasting data Warning Attack Status: These attacks are... class of attacks that exploit a specific weakness common in software Warning Attack Status: New buffer−overrun attacks are found all the time IIS has been hit with so many new buffer overrun attacks