hack proofing your network second edition phần 8 pptx

Tunneling • Chapter 13 547 ~/.ssh/authorized_keys, which the SSH daemon will use to authenticate remote private keys with.Why there isn’t standardized functionality for this is a great mystery; this extended multi-part command, however, will get the job done reasonably well: effugas@OTHERSHOE ~ $ cat ~/.ssh/identity.pub | ssh -1 effugas@10.0.1.10 "cd ~ && umask 077 && mkdir -p .ssh && cat >> ~/.ssh/authorized_keys" effugas@10.0.1.10's password: Look ma, no password requested: effugas@OTHERSHOE ~ $ ssh -1 effugas@10.0.1.10 Last login: Mon Jan 14 05:44:22 2002 from 10.0.1.56 [effugas@localhost effugas]$ The equivalent process for SSH2, the default protocol for OpenSSH: effugas@OTHERSHOE ~ $ cat ~/.ssh/id_dsa.pub | ssh effugas@10.0.1.10 "cd ~ && umask 077 && mkdir -p .ssh && cat >> ~/.ssh/authorized_keys2" effugas@10.0.1.10's password: effugas@OTHERSHOE ~ $ ssh effugas@10.0.1.10 Last login: Mon Jan 14 05:47:30 2002 from 10.0.1.56 [effugas@localhost effugas]$ www.syngress.com Many Users, One Account: Preventing Password Leakage One very important thing to realize is that there may be many entries in each user account’s authorized_keys files. This is often used to allow one user to authenticate to a server from many different accounts; hopefully the various end-to-end techniques described in this chapter will limit the Tools & Traps… Continued 194_HPYN2e_13.qxd 2/15/02 1:05 PM Page 547 548 Chapter 13 • Tunneling Passwords were avoided because we didn’t trust servers, but who says our clients are much better? Great crypto is nice, but we’re essentially taking something that was stored in the mind of the user and putting it on the hard drive of the client for possible grabbing. Remember that there is no secure way to store a password on a client without another password to protect it. Solutions to this problem aren’t great. One system supported by SSH involves passphrases—passwords that are parsed client-side and are used to decrypt the private key that the remote server wishes to verify possession of.You can add passphrases to both SSH2 keys: # add passphrase to SSH1 key effugas@OTHERSHOE ~ $ ssh-keygen.exe -p Enter file in which the key is (/home/effugas/.ssh/identity): Key has comment 'effugas@OTHERSHOE' Enter new passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved with the new passphrase. # add passphrase to SSH2 key effugas@OTHERSHOE ~ $ ssh-keygen.exe -t dsa -p Enter file in which the key is (/home/effugas/.ssh/id_dsa): www.syngress.com usage of that insecure methodology. (The more hosts can log in, the more external compromises may lead to internal damage.) However, there is still an excellent use for the fact that autho- rized_keys and authorized_keys2 may store many entries—giving multiple individuals access to a single account, with none of them knowing the permanent password to that account. New members of a group add their public component to some account with necessary permissions; from then on, their personal key gets them in. Should they leave the group, their individual public element is removed from the list of autho- rized_keys; nobody else has to remember a new password! A slight caveat—known_hosts2 and authorized_keys2 are being slowly eliminated, being condensed into the master known_hosts and authorized_keys files. Servers that don’t work by using the SSH2-specific files may work simply by cutting off the 2 from the end of the file in question. 194_HPYN2e_13.qxd 2/15/02 1:05 PM Page 548 Tunneling • Chapter 13 549 Key has comment '/home/effugas/.ssh/id_dsa' Enter new passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved with the new passphrase. # Note the new request for passphrases effugas@OTHERSHOE ~ $ ssh effugas@10.0.1.11 Enter passphrase for key '/home/effugas/.ssh/id_dsa': FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3 13:44:59 GMT 2001 $ Of course, now we’re back where we started—we have to enter a password every time we want to log into a remote host! What now? Well, the dark truth is that most people just trust their clients and stay completely passphrase-free, much to the annoyance of IT administrators who think disabling passwords entirely will drive people towards a really nice crypto solution that has no huge wide-open holes. SSH does have a system that tries to address the problem of passphrases being no better than passwords, by allowing a single entry of the passphrase to spread among many authentication attempts.This is done through an agent, which sits around and serves private key computations to SSH clients run under it. (This means, importantly, that only SSH clients running under the shell of the agent get access to its key.) Passphrases are given to the agent, which then decrypts the private key and lets clients access it password-free. A sample implementation of this, assuming keys created as in the earlier example and authorized on both 10.0.1.11 and 10.0.1.10: First, we start the agent. Note that there is a child shell that is named. If you don’t name a shell, you’ll get an error along the lines of “Could not open a connection to your authentication agent.” effugas@OTHERSHOE ~ $ ssh-agent bash Now, add the keys. If there’s no argument, the SSH1 key is added: effugas@OTHERSHOE ~ $ ssh-add Enter passphrase for effugas@OTHERSHOE: Identity added: /home/effugas/.ssh/identity (effugas@OTHERSHOE) www.syngress.com 194_HPYN2e_13.qxd 2/15/02 1:05 PM Page 549 550 Chapter 13 • Tunneling With an argument, the SSH2 key is tossed on: effugas@OTHERSHOE ~ $ ssh-add ~/.ssh/id_dsa Enter passphrase for /home/effugas/.ssh/id_dsa: Identity added: /home/effugas/.ssh/id_dsa (/home/effugas/.ssh/id_dsa) Now, let’s try to connect to a couple hosts that have been programmed to accept both keys: effugas@OTHERSHOE ~ $ ssh -1 effugas@10.0.1.10 Last login: Mon Jan 14 06:20:21 2002 from 10.0.1.56 [effugas@localhost effugas]$ ^D effugas@OTHERSHOE ~ $ ssh -2 effugas@10.0.1.11 FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3 13:44:59 GMT 2001 $ Having achieved a connection to a remote host, we now have to figure what to do. For any given SSH connection, we may execute commands on the remote server or establish various forms of network connectivity.We may even do both, sometimes providing ourselves a network path to the very server we just initiated. Command Forwarding: Direct Execution for Scripts and Pipes One of the most useful features of SSH derives from its heritage as a replacement for the r* series of UNIX applications. SSH possesses the capability to cleanly execute remote commands, as if they were local. For example, instead of typing: effugas@OTHERSHOE ~ $ ssh effugas@10.0.1.11 effugas@10.0.1.11's password: FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3 13:44:59 GMT 2001 $ uptime 3:19AM up 18 days, 8:48, 5 users, load averages: 2.02, 2.04, 1.97 $ www.syngress.com 194_HPYN2e_13.qxd 2/15/02 1:05 PM Page 550 Tunneling • Chapter 13 551 We could just type: effugas@OTHERSHOE ~ $ ssh effugas@10.0.1.11 uptime effugas@10.0.1.11's password: 3:20AM up 18 days, 8:49, 4 users, load averages: 2.01, 2.03, 1.97 Indeed, we can pipe output between hosts, such as in this trivial example: effugas@OTHERSHOE ~ $ ssh effugas@10.0.1.11 "ls –l" | grep usocks effugas@10.0.1.11's password: drwxr-xr-x 2 effugas effugas 1024 Aug 5 20:36 usocksd-0.9.3 -rw-r r 1 effugas effugas 54049 Jan 14 20:21 usocksd- 0.9.3.tar.gz Such functionality is extraordinarily useful for tunneling purposes.The basic concept of a tunnel is something that creates a data flow across a normally impenetrable boundary; there is little that is generically as impenetrable as the separation between two independent pieces of hardware. (A massive amount of work has been done in process compartmentalization, where a failure in one piece of code is almost absolutely positively not going to cause a failure somewhere else, due to absolute memory protection, CPU scheduling, and what not. Meanwhile, simply running your Web server and mail server code on different systems, possible many different systems, possibly geographically spread over the globe provides a completely different class of process separation.) SSH turns pipes into an inter-host communication subsystem—the rule becomes: Almost any time you’d use a pipe to transfer data between processes, SSH allows the processes to be located on other hosts. NOTE Not all commands were built to be piped—those that take over the terminal screen and draw to it, like lynx, elm, pine, or tin, require what’s known as a TTY to function correctly. TTYs use unused characters to allow for various drawing modes and styles, and as such are not 8-bit clean in the way pipes need to be. SSH still supports TTY-using commands, but the –t option must be specified. www.syngress.com 194_HPYN2e_13.qxd 2/15/02 1:05 PM Page 551 552 Chapter 13 • Tunneling Remote pipe execution can be used to great effect—very simple command pipelines, suddenly able to cross server boundaries, can have extraordinarily useful effects. For example, most file transfer operations can be built using little more than a few basic tools that ship with almost all UNIX and Cygwin distributions. Some base elements are listed in Table 13.3: Table 13.3 Useful Shell Script Components for SSH Command Forwards Symbol Command Description | Pipeline. Forwards output from the app on the left side to the app on the right side ; Semicolon. Allows multiple commands to be executed in a pipeline && Logical AND Allows multiple commands to be executed in a pipeline, but stops the pipe if any individual command fails > File Redirect Forwards output from the app on the left side to the filename on the right side >> File Append Forwards output from the app on the left side to the end of the file on the right side cat Concatenate cat: Forwards output from the stream on the left side (which may be an application or a pipeline) into a stream on the right side (which may then be redirected into a file or piped into another application); cat file: Outputs file into a stream of bytes ls List Files Outputs a directory listing tar Tape Archive tar –cf - /path: Translate from directory and files within into a stream of bytes tar –xf -: Translate tar-stream of bytes into directories and files head Read Beginning head –c 100 -: Output first 100 bytes of stream head –c 100 file: Output first 100 bytes of file tail Read Ending tail –c 100 -: Output last 100 bytes of strea tail –c 100 file: Output last 100 bytes of file From such simple beginnings, we can actually implement the basic elements of a file transfer system (see Table 13.4). www.syngress.com 194_HPYN2e_13.qxd 2/15/02 1:05 PM Page 552 Tunneling • Chapter 13 553 Table 13.4 Transferring Files Using Generic Shell Components Command SSH Equivalent Explanation GET ssh user@host “cat file” > file “Have the remote host output the contents of some remote file, and redirect those bytes into a local file.” PUT cat file | ssh user@host “cat > file” “Have the local host output the contents of some local file, accept the stream on the remote host, and redirect it into a remote file.” LIST ssh user@host ls /path “Have the remote host list all files available in a specific remote path.” MGET ssh user@host “tar cf - /path” “Output the files and direc- | tar –xf - tories of a remote directory as a tar-formatted bytestream and pipe that through a local tarball extractor, which will re- create the remote files locally.” MPUT tar –cf - /path | ssh user@host “Translate the files and - “tar –xf –” directories of a local directory into a tar-formatted bytestream and pipe that through a remote tarball translator, which will re- create the local files remotely.” RESUME ssh user@host “tail –c “Determine the amount left GET remote_filesize –local_filesize to get and grab only the file” >> file required number of bytes.” RESUME tail –c local_filesize-remote_filesize “Determine the amount left PUT file >> file to put and send only the required number of bytes.” One of the very nice things about SSH is that, when it executes commands remotely, it does so in an extraordinarily restricted context.Trusted paths are actually compiled into the SSH daemon, and the only binaries SSH will execute www.syngress.com 194_HPYN2e_13.qxd 2/15/02 1:05 PM Page 553 554 Chapter 13 • Tunneling without an absolute path are those in /usr/local/bin, /usr/bin, and /bin. (SSH also has the capability to forward environment variables, so if the client shell has any interesting paths, their names will be sent to the server as well.This is a slight sacrifice of security for a pretty decent jump in functionality.) www.syngress.com su: Silly User, Root Is For Kids The su tool is probably the ultimate paper tiger of the secure software world. As a command-line tool intended to allow an individual to “switch user” permissions, it is held up as a far superior alternative to directly connecting to the required account in the first place. Even the venerable OpenBSD makes this mistake: $ ssh root@10.0.1.220 root@10.0.1.220's password: Last login: Fri Dec 28 02:02:16 2001 from 10.0.1.150 OpenBSD 2.7 (GENERIC) #13: Sat May 13 17:41:03 MDT 2000 Welcome to OpenBSD: The proactively secure Unix-like operating system. Please use the sendbug(1) utility to report bugs in the system. Before reporting a bug, please try to reproduce it with the latestversion of the code. With bug reports, please try to ensure thatenough information to reproduce the problem is enclosed, and if aknown fix for it exists, include that as well. Terminal type? [xterm] Don't login as root, use su spork# This advice is ridiculous, as it’s intended: The idea is that a user should go about his business normally in his normal account and, in case Notes from the Underground… Continued 194_HPYN2e_13.qxd 2/15/02 1:05 PM Page 554 Tunneling • Chapter 13 555 www.syngress.com he needs to complete some administrative task, he should then instruct his user shell—the one not trusted to administer the system—to launch a program that will ask for a root password and in return provide a shell that is indeed trusted. That would be great if we had any assurance that the user shell was actually going to execute SU! Think about it—there are innumerable opportunity for a shell to be corrupted, if nothing else by .bashrc/.profile/.tcshrc automatic and invisible configuration files. Each of these files could specify an alternate executable to load, rather than the genuine su, which would capture the keyboard traffic of a root password being entered in and either write that to a file or send it over the network. If there is to be a dividing line between the account of an average user and the root account, what sense does it make to pipe that which upgrades from the former untrusted to the latter trusted through a resource wholly owned and controlled in “enemy territory?” It’s exactly analo- gous to leaving the fox in charge of the henhouse; the specific entity we fail to trust is being given the keys to that realm we absolutely need to maintain secure, and our assumption is that with those keys no evil will be done. If we trusted it to do no evil, we wouldn’t be putting restrictions upon it in the first place! Unfortunately, particularly when multiple people share root access on a machine, it’s critical to know who came in and broke something at what time. The su tool is nice because it provides a very clean log entry that shows who traveled from lower security to high. Even creating individual authorized_keys entries in root doesn’t handle this sufficiently, because it doesn’t really log which key was used to get into what account (this should be fixed in a later release). This need for accountability is so great that it actually can reasonably outweigh the restriction concept on individual accounts, which may not even be there as a real security system anyway—in other words, root is something you always have access to, but you want to be able to prevent accidental and casual command-line work from wiping out the server! Can we keep this accountability without necessarily forcing a critical password through an insecure space? Yes—using SSH. When SSH executes a command forward, it does so using the very limited default environment that the shell provides. This default environment—a com- bination of the root-owned sshd and the root owned /bin/sh, with an ignorable bit from the client—is immune to whatever corruptions might happen to the shell in its configuration files or whatnot. That makes it a perfect environment for su! Continued 194_HPYN2e_13.qxd 2/15/02 1:05 PM Page 555 556 Chapter 13 • Tunneling Port Forwarding: Accessing Resources on Remote Networks Once we’ve got a link, SSH gives us the capability to create a “portal” of limited network connectivity from the client to the server, or vice versa.The portal is not total—simply running SSH does not magically encapsulate all network traffic on your system, any more than the existence of airplanes means you can flap your arms and fly. However, there do exist methods and systems for making SSH an extraordinarily useful network tunneling system. www.syngress.com ssh user@host -t "/bin/su –l user2" This drops down into the first user’s account just long enough to authenticate—the environment is kept as pure as the root-owned processes that spawned it. In this pure environment, su is given a TTY and told to switch to some second user. Because it’s the pure environment, we know it’s actually su that’s being executed, not anything else. Note that only /bin/sh can be trusted to maintain command environment purity. Bash, for example, will load its config files even when simply being used to execute a command. A chsh (change shell) command will need to be executed for this method to remain safe. This doesn’t, however, mean that users need to switch from bash to /bin/sh— using a .profile configuration in their home directory, a user could place exec bash —login –i and have bash access when logged in interactively while still having the safe environment available for remote commands. There is another problem, little known but of some import. Even for command forwards, the file ~/.ssh/environment is loaded by SSHD to set custom environmental parameters. The primary environment parameter to attack would be the launch path for the remote su; by redirecting the path to some corrupted binary owned by the user, anything typed at the command line would be vulnerable. It’s nontrivial to disable ~/.ssh/environment file parsing, but it’s easy to simply specify an absolute path to su—/bin/su , usually, though it’s occasionally /usr/bin/su—that path hacking can’t touch. The other major environment hack involves library preloads, which change the functions that a given app might depend on to execute. Because su is a setuid app, the system will automatically ignore any library preloads. Finally, it is critical to use the –l option to su to specify that the full login environment should be cleared once the connection is established. Otherwise, pollution from the user shell will spread up to the root shell! 194_HPYN2e_13.qxd 2/15/02 1:05 PM Page 556 [...]... port 10 080 and forward all httptunnel requests to its own port 22: [effugas@localhost effugas]$ hts 10 080 -F 127.0.0.1:22 Start a httptunnel client on the client that will listen on port 10022, bounce any traffic that arrives through the HTTP proxy on 10.0.1.11 :88 88 into whatever is being hosted by the httptunnel server at 10.0.1.10:10 080 : effugas@OTHERSHOE ~/.ssh $ htc -F 10022 -P 10.0.1.11 :88 88 10.0.1.10:10 080 ... direct-tcpip: listening port 1 080 for 216.7.64.9 port 80 , connect from 127.0.0.1 port 2166 (t4 r1 i1/0 o16/0 fd 8/ 8) #3 direct-tcpip: listening port 1 080 for 216.7.64.14 port 80 , connect from 127.0.0.1 port 21 98 (t4 r2 i1/0 o16/0 fd 9/9) www.syngress.com 561 194_HPYN2e_13.qxd 562 2/15/02 1:05 PM Page 562 Chapter 13 • Tunneling #4 direct-tcpip: listening port 1 080 for 216.7.64.14 port 80 , connect from 127.0.0.1... bouncing off somewhere, like your server at home or school, you’re not going anywhere 1 Select My AIM | Edit Options | Edit Preferences 2 Click Sign On/Off along the bar on the left 3 Click Connection to “configure AIM for your proxy server” 4 Check Connect Using Proxy, and select SOCKS4 as your protocol 5 Use 127.0.0.1 as your host and 1 080 (or whatever else you used) for your port 6 Click OK on both... changing the way SSH is perceived on the network, or changing the path the data takes through the network itself Crossing the Bridge: Accessing Proxies through ProxyCommands It is actually a pretty rare network that doesn’t directly permit outgoing SSH connectivity; when such access isn’t available, often it is because those networks are restricting all outgoing network connectivity, forcing it to be... resolve names and remain stable through adverse network conditions Launching it isn’t too bad: Dan@EFFUGAS ~ $ ssh -L2 080 :127.0.0.1:2 080 effugas@10.0.1.11 "./usocksd -p 2 080 " effugas@10.0.1.11's password: usocksd version 0.9.3 (c) Olaf Titz 1997-1999 Accepting connnections from (anywhere) ident (anyone) Relaying UDP from (anywhere) Listening on port 2 080 We use both command forwarding and port forwarding... -L6667:newyork.ny.us.undernet.org:6667 Password: Last login: Mon Jan 14 06:22:19 2002 from some.net on pts/0 Linux libertiee.net 2.4.17 #2 Mon Dec 31 21: 28: 05 PST 2001 i 686 unknown Last login: Mon Jan 14 06:23:45 2002 from some.net libertiee:~> www.syngress.com 557 194_HPYN2e_13.qxd 5 58 2/15/02 1:05 PM Page 5 58 Chapter 13 • Tunneling Let’s see if the forwarding worked—do we get the same output from localhost that we used to be getting... from within another network very useful when IRC doesn’t work from behind your firewall due to identd.This is the raw traffic that arrives when the port is connected to: effugas@OTHERSHOE ~ $ telnet newyork.ny.us.undernet.org 6667 Trying 66.100.191.2 Connected to newyork.ny.us.undernet.org Escape character is '^]' NOTICE AUTH :*** Looking up your hostname NOTICE AUTH :*** Found your hostname, cached... these issues, we use pathbased hacks Show Your Badge: Restricted Bastion Authentication Many networks are set up as follows: One server is publicly accessible on the global Internet, and provides firewall, routing, and possibly address translation services for a set of systems behind it.These systems are known as bastion hosts—they are the interface between the private network and the real world It is... SSH client instead of some open proxy on the network effugas@OTHERSHOE ~ $ ssh -D1 080 effugas@10.0.1.11 effugas@10.0.1.11's password: FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3 13:44:59 GMT 2001 $ effugas@OTHERSHOE ~ $ ssh -o ProxyCommand="connect -4 -S 127.0.0.1:1 080 %h %p" root@ 10.0.1.10 root@10.0.1.10's password: Last login: Thu Jan 10 13:12: 28 2002 from 10.0.1.11 [root@localhost root]#... Common usage of the File Transfer Protocol among administrators managing variously firewalled networks involves the host that can’t receive connections always generating outgoing links to the host that can, regardless of the eventual direction www.syngress.com 581 194_HPYN2e_13.qxd 582 2/15/02 1:05 PM Page 582 Chapter 13 • Tunneling of data flow (FTP itself, a strange protocol to say the least, needs . port 1 080 for 216.7.64.9 port 80 , connect from 127.0.0.1 port 2166 (t4 r1 i1/0 o16/0 fd 8/ 8) #3 direct-tcpip: listening port 1 080 for 216.7.64.14 port 80 , connect from 127.0.0.1 port 21 98 (t4. “configure AIM for your proxy server”. 4. Check Connect Using Proxy, and select SOCKS4 as your protocol. 5. Use 127.0.0.1 as your host and 1 080 (or whatever else you used) for your port. 6. Click. remain stable through adverse network conditions. Launching it isn’t too bad: Dan@EFFUGAS ~ $ ssh -L2 080 :127.0.0.1:2 080 effugas@10.0.1.11 "./usocksd -p 2 080 " effugas@10.0.1.11's