hack proofing your network second edition phần 7 pptx

Spoofing: Attacks on Trusted Identity • Chapter 12 459 Ability to transmit ends up being the most basic level of security that gets implemented. Even the weakest, most wide-open remote access service cannot be attacked by an untrusted user if that user has no means to get a message to the vulnerable system. Unfortunately, depending upon a firewall to strip the ability to transmit messages from anyone who might threaten your network just isn’t enough to really secure it. For one, unless you use a “military-style firewall” (read: air firewall, or a complete lack of connection between the local network and the global Internet), excess paths are always likely to exist.The Department of Defense continues: “The principle underlying response planning should be that of ‘graceful degradation’; that is, the system or network should lose functionality gradually, as a function of the severity of the attack compared to its ability to defend against it.” Ability to Respond:“Can It Respond to Me?” One level up from the ability to send a message is the ability to respond to one. Quite a few protocols involve some form of negotiation between sender and receiver, though some merely specify intermittent or on-demand proclamations from a host announcing something to whomever will listen.When negotiation is required, systems must have the capability to create response transmissions that relate to content transmitted by other hosts on the network.This is a capability above and beyond mere transmission, and is thus separated into the ability to respond. Using the ability to respond as a method of the establishing the integrity of the source’s network address is a common technique.As much as many might like source addresses to be kept sacrosanct by networks and for spoofing attacks the world over to be suppressed, there will always be a network that can claim to be passing an arbitrary packet while in fact it generated it instead. To handle this, many protocols attempt to cancel source spoofing by transmit- ting a signal back to the supposed source. If a response transmission, containing “some aspect” of the original signal shows up, some form of interactive connec- tivity is generally presumed. This level of protection is standard in the TCP protocol itself—the three-way handshake can essentially be thought of as,“Hi, I’m Bob.”“I’m Alice.You say you’re Bob?”“Yes,Alice, I’m Bob.” If Bob tells Alice,“Yes,Alice, I’m Bob,” and Alice hasn’t recently spoken to Bob, then the protocol can determine that a blind spoofing attack is taking place. (In actuality, protocols rarely look for attacks; rather, www.syngress.com 194_HPYN2e_12.qxd 2/15/02 12:58 PM Page 459 460 Chapter 12 • Spoofing: Attacks on Trusted Identity they function only in the absence of attacks.This is because most protocols are built to establish connectivity, not fend off attackers. But it turns out that by failing to function, save for the presence of some moderately difficult to capture data values, protocols end up significantly increasing their security level simply by vastly reducing the set of hosts that could easily provide the necessary values to effect an attack. Simply reducing the set of hosts that can execute a direct attack from “any machine on the Internet” to “any machine on one of the ten subnets in between the server and the client” can often reduce the number of hosts able to mount an effective attack by many orders of magnitude!) In terms of network-level spoofs against systems that challenge the ability to respond, there are two different attack modes: blind spoofs, where the attacker has little to no knowledge of the network activity going in or coming out of a host (specifically, not the thus-far unidentified variable that the protocol is challenging this source to respond with), and active spoofs, where the attacker has at least the full capability to sniff the traffic exiting a given host and possibly varying degrees of control over that stream of traffic.We discuss these two modes separately. Blind Spoofing In terms of sample implementations, the discussions regarding connection hijacking in Chapter 11 are more than sufficient. From a purely theoretical point of view, however, the blind spoofer has one goal: Determine a method to predict changes in the variable (predictive), then provide as many possible transmissions as the protocol will withstand to hopefully hit the single correct one (probabilistic) and successfully respond to a transmission that was never received. One of the more interesting results of developments in blind spoofing has been the discovery of methods that allow for blind scanning of remote hosts. It is, of course, impossible to test connectivity to a given host or port without sending a packet to it and monitoring the response (you can’t know what would happen if you sent a packet without actually having a packet sent), but blind scanning allows for a probe to examine a subject without the subject being aware of the source of the probing. Connection attempts are sent as normal, but they are spoofed as if they came from some other machine, known as a zombie host.This zombie has Internet connectivity but barely uses it—a practically unused server, for instance. Because it’s almost completely unused, the prober may presume that all traffic in and out of this “zombie” is the result of its action, either direct or indirect. The indirect traffic, of course, is the result of packets returned to the zombie from the target host being probed. www.syngress.com 194_HPYN2e_12.qxd 2/15/02 12:58 PM Page 460 Spoofing: Attacks on Trusted Identity • Chapter 12 461 For blind scanning, the probing host must somehow know that the zombie received positive responses from the target.Antirez discovered exactly such a technique, and it was eventually integrated into Fyodor’s nmap as the –sI option. The technique employed the IPID field. Used to reference one packet to another on an IP level for fragmentation reference purposes, IPIDs on many operating systems are simply incremented by one for each packet sent. (On Windows, this increment occurs in little-endian order, so the increments are generally by 256. But the core method remains the same.) Now, in TCP, when a host responds pos- itively to a port connection request (a SYN), it returns a connection request acknowledged message (a SYN|ACK). But when the zombie receives the SYN|ACK, it never requested a connection, so it tells the target to go away and reset its connection.This is done with a RST|ACK, and no further traffic occurs for that attempt.This RST|ACK is also sent by the target to the zombie if a port is closed, and the zombie sends nothing in response. What’s significant is that the zombie is sending a packet out—the RST|ACK—every time the prober hits an open port on the target.This packet being sent increments the IPID counter on the zombie. So the prober can probe the zombie before and after each attempt on the target, and if the IPID field has incremented more times than the zombie has sent packets to the prober, the prober can assume the zombie received SYN|ACKs from the target and replied with RST|ACKs of its own. And thus, a target can be probed without ever knowing who legitimately probed it, while the prober can use almost any arbitrary host on the Internet to hide its scans behind. A blind scan is trivial in nmap; simply use nmap –sI zombie_host:port target:port and wait. For further information, read www.bursztein.net/secu/temoinus.html. Active Spoofing Most variable requests are trivially spoofable if you can sniff their release.You’re just literally proving a medium incorrect when it assumes that only trusted hosts will be able to issue a reply.You’re untrusted, you found a way to actively discover the request, and you’ll be able to reply.You win—big deal. What’s moderately more interesting is the question of modulation of the existing datastream on the wire.The ability to transmit doesn’t grant much con- trol over what’s on the wire—yes, you should be able to jam signals by overpow- ering them (specifically relevant for radio frequency–based media)—but generally transmission ability does not imply the capability to understand whatever anyone else is transmitting. Response spoofing is something more; if you’re able to www.syngress.com 194_HPYN2e_12.qxd 2/15/02 12:58 PM Page 461 462 Chapter 12 • Spoofing: Attacks on Trusted Identity actively determine what to respond to, that implies some advanced ability to read the bits on the wire (as opposed to the mere control bits that describe when a transmission may take place). This doesn’t mean you can respond to everything on the wire—the ability to respond is generally tapped for anything but the bare minimum for transmission. Active bit-layer work in a data medium can include the following subcapabilities: ■ Ability to sniff some or all preexisting raw bits or packets Essentially, you’re not adding to the wire, but you’re responding to trans- missions upon it by storing locally or transmitting on another wire. ■ Ability to censor (corrupt) some or all preexisting raw bits or packets before they reach their destination Your ability to transmit within a medium has increased—now, you can scrub individual bits or even entire packets if you so choose. ■ Ability to generate some or all raw bits or packets in response to sniffed packets The obvious capability, but obviously not the only one. ■ Ability to modify some or all raw bits or packets in response to their contents Sometimes, making noise and retransmitting is not an option. Consider live radio broadcasts. If you need to do modification on them based on their content, your best bet is to install a sufficient signal delay (or co-opt the existing delay hardware) before it leaves the tower. Modulation after it’s in the air isn’t inconceivable, but it’s pretty close. ■ Ability to delete some or all raw bits or packets in response to their contents Arbitrary deletion is harder than modification, because you lose sync with the original signal. Isochronous (uniform bitrate) streams require a delay to prevent the transmission of false nulls (you should be sending something, right? Dead air is something.). It is entirely conceivable that any of these subcapabilities may be called upon to legitimately authenticate a user to a host.With the exception of packet corruption (which is essentially done only when deletion or elegant modification is unavail- able and the packet absolutely must not reach its destination), these are all common operations on firewalls, virtual private networks’ (VPNs) concentrators, and even local gateway routers. www.syngress.com 194_HPYN2e_12.qxd 2/15/02 12:58 PM Page 462 Spoofing: Attacks on Trusted Identity • Chapter 12 463 What Is the Variable? We’ve talked a lot about a variable that might need to be sniffed, or probabilisti- cally generated, or any other of a host of options for forging the response ability of many protocols. But what’s the variable? These two abilities—transmission and response—are little more than core con- cepts that represent the ability to place bits on a digital medium, or possibly to interpret them in one of several manners. They do not represent any form of intelli- gence regarding what those bits mean in the context of identity management. The remaining four layers handle this load, and are derived mostly from common cryptographic identity constructs. Ability to Encode:“Can It Speak My Language?” The ability to transmit meant the user could send bits, and the ability to respond meant that the user could listen to and reply to those bits if needed. But how to know what’s needed in either direction? Thus enters the ability to encode, which means that a specific host/user has the capability to construct packets that meet the requirements of a specific protocol. If a protocol requires incoming packets to be decoded, so be it—the point is to support the protocol. For all the talk of IP spoofing,TCP/IP is just a protocol stack, and IP is just another protocol to support. Protections against IP spoofing are enforced by using protocols (like TCP) that demand an ability to respond before initiating communi- cations, and by stripping the ability to transmit (dropping unceremoniously in the bit bucket, thus preventing the packet from transmitting to protected networks) from incoming or outgoing packets that were obviously source-spoofed. In other words, all the extensive protections of the last two layers may be implemented using the methods I described, but they are controlled by the encoding authenticator and above. (Not everything in TCP is mere encoding.The random- ized sequence number that needs to be returned in any response is essentially a very short-lived “shared secret” unique to that connection. Shared secrets are dis- cussed further in the next section.) Now, although obviously encoding is necessary to interact with other hosts, this isn’t a chapter about interaction—it’s a chapter about authentication. Can the mere ability to understand and speak the protocol of another host be sufficient to authenticate one for access? Such is the nature of public services. www.syngress.com 194_HPYN2e_12.qxd 2/15/02 12:58 PM Page 463 464 Chapter 12 • Spoofing: Attacks on Trusted Identity Most of the Web serves entire streams of data without so much as a blink to clients whose only evidence of their identity can be reduced down to a single HTTP call: GET /. (That’s a period to end the sentence, not an obligatory Slashdot reference. This is an obligatory Slashdot reference.) The GET call is documented in RFCs (RFC1945) and is public knowledge. It is possible to have higher levels of authentication supported by the protocol, and the upgrade to those levels is reasonably smoothly handled. But the base public access system depends merely on one’s knowledge of the HTTP protocol and the ability to make a successful TCP connection to port 80. Not all protocols are as open, however.Through either underdocumentation or restriction of sample code, many protocols are entirely closed.The mere ability to speak the protocol authenticates one as worthy of what may very well repre- sent a substantial amount of trust; the presumption is, if you can speak the lan- guage, you’re skilled enough to use it. That doesn’t mean anyone wants you to, unfortunately. The war between open source and closed source has been waged quite harshly in recent times and will continue to rage.There is much that is uncertain; however, there is one specific argument that can actually be won. In the war between open protocols versus closed protocols, the mere ability to speak to one or the other should never, ever, ever grant you enough trust to order workstations to execute arbitrary commands. Servers must be able to provide something— maybe even just a password—to be able to execute commands on client machines. Unless this constraint is met, a deployment of a master server anywhere con- ceivably allows for control of hosts everywhere. Who made this mistake? Both Microsoft and Novell. Neither company’s client software (with the pos- sible exception of a Kerberized Windows 2000 network) does any authentication on the domains they are logging in to beyond verifying that, indeed, they know how to say “Welcome to my domain. Here is a script of commands for you to run upon login.”The presumption behind the design was that nobody would ever be on a LAN (local area network) with computers they owned themselves; the physical security of an office (the only place where you find LANs, appar- ently) would prevent spoofed servers from popping up.As I wrote back in May of 1999: “A common aspect of most client-server network designs is the login script. A set of commands executed upon provision of correct www.syngress.com 194_HPYN2e_12.qxd 2/15/02 12:58 PM Page 464 Spoofing: Attacks on Trusted Identity • Chapter 12 465 username and password, the login script provides the means for corporate system administrators to centrally manage their flock of clients. Unfortunately, what’s seemingly good for the business turns out to be a disastrous security hole in the University environment, where students logging in to the network from their dorm rooms now find the network logging in to them. This hole provides a single, uniform point of access to any number of previously uncom- promised clients, and is a severe liability that must be dealt with the highest urgency. Even those in the corporate environment should take note of their uncomfortable exposure and demand a number of security procedures described herein to protect their networks.” —Dan Kaminsky “Insecurity by Design: The Unforeseen Consequences of Login Scripts” www.doxpara.com/login.html Ability to Prove a Shared Secret: “Does It Share a Secret with Me?” This is the first ability check where a cryptographically secure identity begins to form. Shared secrets are essentially tokens that two hosts share with one another. They can be used to establish links that are: ■ Confidential The communications appear as noise to any other hosts but the ones communicating. ■ Authenticated Each side of the encrypted channel is assured of the trusted identity of the other. ■ Integrity Checked Any communications that travel over the encrypted channel cannot be interrupted, hijacked, or inserted into. Merely sharing a secret—a short word or phrase, generally—does not directly win all three, but it does enable the technologies to be deployed reasonably straightforwardly.This does not mean that such systems have been.The largest deployment of systems that depend upon this ability to authenticate their users is by far the password contingent. Unfortunately,Telnet is about the height of pass- word-exchange technology at most sites, and even most Web sites don’t use the Message Digest 5 (MD5) standard to exchange passwords. It could be worse; passwords to every company could be printed in the classi- fied section of the New York Times.That’s a comforting thought.“If our firewall goes, every device around here is owned. But, at least my passwords aren’t in the New York Times.” www.syngress.com 194_HPYN2e_12.qxd 2/15/02 12:58 PM Page 465 466 Chapter 12 • Spoofing: Attacks on Trusted Identity All joking aside, there are actually deployed cryptosystems that do grant cryp- tographic protections to the systems they protect.Almost always bolted onto decent protocols with good distributed functionality but very bad security (ex: RIPv2 from the original RIP, and TACACS+ from the original TACACS/XTA- CACS), they suffer from two major problems: First, their cryptography isn’t very good. Solar Designer, with an example of what every security advisory would ideally look like, talks about TACACS+ in “An Analysis of the TACACS+ Protocol and its Implementations.”The paper is located at www.openwall.com/advisories/OW-001-tac_plus.txt. Spoofing packets such that it would appear that the secret was known would not be too difficult for a dedicated attacker with active sniffing capability. Second, and much more importantly, passwords lose much of their power once they’re shared past two hosts! Both TACACS+ and RIPv2 depend on a single, shared pass- word throughout the entire usage infrastructure (TACACS+ actually could be rewritten not to have this dependency, but I don’t believe RIPv2 could).When only two machines have a password, look closely at the implications: ■ Confidential? The communications appear as noise to any other hosts but the ones communicating…but could appear as plaintext to any other host who shares the password. ■ Authenticated? Each side of the encrypted channel is assured of the trusted identity of the other…assuming none of the other dozens, hun- dreds, or thousands of hosts with the same password have either had their passwords stolen or are actively spoofing the other end of the link themselves. ■ Integrity Checked? Any communications that travel over the encrypted channel cannot be interrupted, hijacked, or inserted into, unless somebody leaked the key as above. Use of a single, shared password between two hosts in a virtual point-to-point connection arrangement works, and works well. Even when this relationship is a client-to-server one (for example, with TACACS+, assume but a single client router authenticating an offered password against CiscoSecure, the backend Cisco password server), you’re either the client asking for a password or the server offering one. If you’re the server, the only other host with the key is a client. If you’re the client, the only other host with the key is the server that you trust. However, if there are multiple clients, every other client could conceivably become your server, and you’d never be the wiser. Shared passwords work great www.syngress.com 194_HPYN2e_12.qxd 2/15/02 12:58 PM Page 466 Spoofing: Attacks on Trusted Identity • Chapter 12 467 for point-to-point, but fail miserably for multiple clients to servers:“The other end of the link” is no longer necessarily trusted. NOTE Despite that, TACACS+ allows so much more flexibility for assigning access privileges and centralizing management that, in spite of its weak- nesses, implementation and deployment of a TACACS+ server still remains one of the better things a company can do to increase security. That’s not to say that there aren’t any good spoof-resistant systems that depend upon passwords. Cisco routers use SSH’s password-exchange systems to allow an engineer to securely present his password to the router.The password is used only for authenticating the user to the router; all confidentiality, link integrity, and (because we don’t want an engineer giving the wrong device a password!) router-to-engineer authentication is handled by the next layer up: the private key. Ability to Prove a Private Keypair: “Can I Recognize Your Voice?” Challenging the ability to prove a private keypair invokes a cryptographic entity known as an asymmetric cipher. Symmetric ciphers, such as Triple-DES, Blowfish, and Twofish, use a single key to both encrypt a message and decrypt it. See Chapter 6 for more details. If just two hosts share those keys, authentication is guaranteed—if you didn’t send a message, the host with the other copy of your key did. The problem is, even in an ideal world, such systems do not scale. Not only must every two machines that require a shared key have a single key for each host they intend to speak to—an exponential growth problem—but those keys must be transferred from one host to another in some trusted fashion over a network, floppy drive, or some data transference method. Plaintext is hard enough to transfer securely; critical key material is almost impossible. Simply by spoofing oneself as the destination for a key transaction, you get a key and can impersonate two people to each other. Yes, more and more layers of symmetric keys can be (and in the military, are) used to insulate key transfers, but in the end, secret material has to move. www.syngress.com 194_HPYN2e_12.qxd 2/15/02 12:58 PM Page 467 468 Chapter 12 • Spoofing: Attacks on Trusted Identity Asymmetric ciphers, such as RSA, Diffie-Helman/El Gamel, offer a better way. Asymmetric ciphers mix into the same key the ability to encrypt data, decrypt data, sign the data with your identity, and prove that you signed it.That’s a lot of capabilities embedded into one key—the asymmetric ciphers split the key into two: one of which is kept secret, and can decrypt data or sign your indepen- dent identity—this is known as the private key.The other is publicized freely, and can encrypt data for your decrypting purposes or be used to verify your signature without imparting the ability to forge it.This is known as the public key. More than anything else, the biggest advantage of private key cryptosystems is that key material never needs to move from one host to another.Two hosts can prove their identities to one another without having ever exchanged anything that can decrypt data or forge an identity. Such is the system used by PGP. Ability to Prove an Identity Keypair:“Is Its Identity Independently Represented in My Keypair?” The primary problem faced by systems such as PGP is:What happens when people know me by my ability to decrypt certain data? In other words, what happens when I can’t change the keys I offer people to send me data with, because those same keys imply that “I” am no longer “me?” Simple.The British Parliament starts trying to pass a law saying that, now that my keys can’t change, I can be made to retroactively unveil every e-mail I have ever been sent, deleted by me (but not by a remote archive) or not, simply because a recent e-mail needs to be decrypted.Worse, once this identity key is released, they are now cryptographically me—in the name of requiring the ability to decrypt data, they now have full control of my signing identity. The entire flow of these abilities has been to isolate out the abilities most focused on identity; the identity key is essentially an asymmetric keypair that is never used to directly encrypt data, only to authorize a key for the usage of encrypting data. SSH and a PGP variant I’m developing known as Dynamically Rekeyed OpenPGP (DROP) all implement this separation on identity and con- tent, finally boiling down to a single cryptographic pair everything that humanity has developed in its pursuit of trust.The basic idea is simple:A keyserver is updated regularly with short-lifespan encryption/decryption keypairs, and the mail sender knows it is safe to accept the new key from the keyserver because even though the new material is unknown, it is signed by something long term that is known:The long-term key. In this way, we separate our short-term requirements to accept mail from our long-term requirements to retain our iden- tity, and restrict our vulnerability to attack. www.syngress.com 194_HPYN2e_12.qxd 2/15/02 12:58 PM Page 468 [...]... you— is prevent all network access that users themselves don’t explicitly request Surprisingly enough, users are generally pretty good about the code they run to access the Net.Web browsers, for all the heat they take, are probably among the most fault-tolerant, bounds-checking, attacked pieces of code in modern network www.syngress.com 471 194_HPYN2e_12.qxd 472 2/15/02 12:58 PM Page 472 Chapter 12 • Spoofing:... reliable they allowed the service to remain The results should be taken with a grain of salt, but as with much of the material on Cryptome, is well worth the read www.syngress.com 477 194_HPYN2e_12.qxd 478 2/15/02 12:58 PM Page 478 Chapter 12 • Spoofing: Attacks on Trusted Identity Bait and Switch: Spoofing the Presence of SSL Itself If you think about it, really sit down and consider—why does a given user... Implementation: DoxRoute, Section by Section Execution of DoxRoute is pretty trivial: [root@localhost effugas]# /doxroute -r 10.0.1.254 -c -v 10.0.1. 170 ARP REQUEST: Wrote 42 bytes looking for 10.0.1.254 Router Found: 10.0.1.254 at 0:3:E3:0:4E:6B DATA: Sent 74 bytes to 171 .68.10 .70 DATA: Sent 62 bytes to 216.239.35.101 DATA: Sent 60 bytes to 216.239.35.101 DATA: Sent 406 bytes to 216.239.35.101 DATA: Sent 60 bytes... interesting packages for using spoofs to execute man-in-the-middle (MITM) attacks against sessions on your network, with extensive support for a wide range of protocols Good luck building your specific spoof into this DoxRoute provides the infrastructure for answering the question “What if we could put a machine on the network that did…”? Well, if we can spoof an entire router in a few lines of code, spoofing whatever... request, the higher the authentication level should be—thus we allow anyone to ping us, but we demand higher proof to receive a root shell.) The pilot was tricked— www.syngress.com 473 194_HPYN2e_12.qxd 474 2/15/02 12:58 PM Page 474 Chapter 12 • Spoofing: Attacks on Trusted Identity Israeli intelligence earned its pay for that day—but his methods were reasonably sound.What more could he have done? He might... differentiate the Web’s content from your system’s; by bug or design there are methods of removing your system’s pixels leaving the Web to do what it will (In this case, all that was needed was to set two options against each other: First, the fullscreen=1 variable was set in the popup function, increasing the size of the window and removing the borders But then a second, contradictory set of options... built because it wouldn’t elegantly fit within some kernel interface is even greater Particularly when it comes to highly flexible network solutions, the www.syngress.com 194_HPYN2e_12.qxd 2/15/02 12:58 PM Page 4 87 Spoofing: Attacks on Trusted Identity • Chapter 12 highly tuned network implementations built into modern kernels are inappropriate for our uses.We’re looking for systems that break the rules,... an extensive investigation by Caldera (who eventually bought DR-DOS), the information never would have seen the light of day It would have been a perfect win www.syngress.com 475 194_HPYN2e_12.qxd 476 2/15/02 12:58 PM Page 476 Chapter 12 • Spoofing: Attacks on Trusted Identity Subtlety Will Get You Everywhere The Microsoft case gives us excellent insight on the nature of what economically motivated... computer networks is their actual consistency—they’re highly deterministic, and problems generally occur either consistently or not at all.Thus, the infuriating nature of testing for a bug that occurs only intermittently—once every two weeks, every 50,000 +/–3,000 transactions, or so on Such bugs can form the gamma-ray bursts of computer networks—supremely major events in the universe of the network, ... Live!Ware, then RealVideo, or Microsoft Media Player, or some other multimedia application straining to develop marketable information at the cost of their customers’ network security www.syngress.com 194_HPYN2e_12.qxd 2/15/02 12:58 PM Page 473 Spoofing: Attacks on Trusted Identity • Chapter 12 Notes from the Underground… Auto Update as Savior? I’ll be honest: Although it’s quite dangerous that so many . threaten your network just isn’t enough to really secure it. For one, unless you use a “military-style firewall” (read: air firewall, or a complete lack of connection between the local network and. data or sign your indepen- dent identity—this is known as the private key.The other is publicized freely, and can encrypt data for your decrypting purposes or be used to verify your signature without. infrastructure of your site—as an organization gets larger, www.syngress.com 194_HPYN2e_12.qxd 2/15/02 12:58 PM Page 470 Spoofing: Attacks on Trusted Identity • Chapter 12 471 blanket access to