How to Hack UNIX: Part 2
Kurt Seifried Most networks have at least a few UNIX-based machines. These UNIX servers typically provide infrastructure -- network and backend services (company database, etc.), which are a critical component of most networks. Desktops, for example, are useless without file and print servers. Many of these servers are publicly accessible (e.g., DNS, email, and Internet servers) making them easy to attack. Even if the server is internal and cannot be attacked via the Internet, there is still the internal network to worry about. Regardless of how well you use firewalls and other filtering mechanisms to control server access, these tools are not enough on their own. An attacker can walk into an office building, find an unused Ethernet jack, plug in laptop connected to a cell phone and then leave, thereby gaining the ability to attack the network from the inside. Furthermore, a night janitor, for example, could use scanners and probing software (such as Nmap, Nessus, Saint, or Cheops) and quickly build a detailed model of your network with minimal effort. (See Figure 1.) Locking down access controls lists tightly enough so that only legitimate connections occur is inadequate, and is also a lot of work. An attacker could use the IP address of a “trusted” machine and scan various hosts; simply cycling through network IPs at random is sufficient in most cases. There is even specialized scanner software for specific services, for example “scanssh”, a scanner that looks for machines running SSH and tells you what versions they are running. (Some older versions have significant security flaws):
http://www.monkey.org/~provos/scassh.tar.gz-scansshMost of this article, especially the protection techniques, apply equally well to Windows-based networks. This leads to the first major problem: TCP/IP is an inherently insecure protocol, and offers attackers many methods to penetrate your defenses. The majority of TCP/IP traffic is unencrypted, and attackers can view data as it passes by. For example, logging into mail servers and retrieving email can be insecure. (See my article, “Crypto 101”, Sys Admin, May 2000.) Attackers can also spoof the identity of other trusted machines, pretending to be someone they are not, and can even hijack active connections using tools like “HUNT”. Another method is to simply crash the trusted machine, which is relatively easy (especially on LANs), and then use its IP address to connect to servers. Finally, attackers can avoid all network-based defenses and simply scan the company's phone exchange. It's almost certain that any major company will have at least one modem attached to an internal machine that isn't secured. All of these techniques allow the attacker to do an end run around firewalls and IDS systems deployed at the Internet gateway. (Remember the Maginot line?) The solution to many of TCP/IP's problems is encryption -- usually referred to as Virtual Private Networks (VPNs). The best supported standard is IPSec. Many operating systems (e.g., OpenBSD, Solaris, and Windows 2000) even ship with support for it. Unfortunately, deploying this technology can include a significant cost in terms of time, money, and processing power. Servers will need crypto-acceleration hardware (which now starts at $100), and busy clients (e.g., engineering workstations that use large CAD files) will also. Due to the complexity of these systems, it is likely that mistakes will be made in the implementation -- mistakes that an attacker can exploit. Unfortunately, you will probably not find these mistakes until it is too late. Placing IDS in many locations on your network can help. If you have a LAN segment with high security requirements, you can configure most switches to mirror all network data to a certain port, and put an IDS on that port to monitor for attacks. Of course, detecting this kind of activity is only the start -- you need to have a plan to handle it. In any case, it is relatively easy for attackers to slip past IDS by using techniques such as fragmenting. A good IDS is comprised of the Open Source software packages “snort”, which gobbles up network traffic, and “arachNIDS”, which analyzes it. The next major area attackers will typically target is common public services. The general rules of security apply here -- patch where possible, keep things up to date, maintain configuration files, and make sure you have a good set of backups. With many of these services, especially the high-risk public ones, you can place a “proxy” server that the public (and attackers) can connect to in front, thereby reducing the exposure of the real server behind it. DNS It's safe to say that anyone connected to the Internet has at least one DNS server, it is probably running on BIND (Berkley Internet Name Daemon). Bind has a long history of problems, including remote root exploits. The best way to deal with this is make sure that your DNS servers are all up to date (as of Summer 2000, this is 8.2.2P5), and that they are running chrooted as non-root users (the -t, -u, and -g switches can accomplish this). Trying to hide the server version is of little use since there are a variety of queries that can glean it from the server. DNS information should also be protected and, because it provides a phonebook to your network, zone transfers should be strictly limited to other DNS servers within your control. However, this will not stop an attacker from using brute-force methods to find out information. Attackers can, for example, query a.example.org, b.example.org, and so on. When using a dictionary, this is quite effective for discovering hosts. Another method is to use reverse DNS lookups, start with 1.2.3.1, then 1.2.3.2, and continue till you have worked your way through a company's address space. There are many tools to automate these procedures. Logging such DNS queries is a futile exercise since the amount of data generated will be significant, and more importantly, attackers can use third-party DNS servers to do queries, thereby masking their identities. It is advisable to split your DNS servers up into those providing information to the public (e.g., DNS service for *.example.org) and those doing queries for internal machines. This will make it much harder for attackers to try and insert false DNS data into your servers, or to otherwise abuse them. DHCP DHCP is one of my favorite services. Not only does it make life significantly easier for administrators (centralized control of network settings on client machines), but it also provides numerous possibilities for an attacker. ISC's DHCP client for UNIX (one of the most popular) had a root exploit in it, meaning that if an attacker could hijack your DHCP server, or set one up on your network, he could remotely exploit clients. Even if all your DHCP clients were up to date, an attacker still would have many options. For example, if an attacker were to set up a computer, or hijack one on an existing LAN and provide DHCP answers faster than the legitimate DHCP server, clients would use it to configure their network settings. With this, an attacker could give the client a false default gateway, routing all traffic through the compromised machine, allowing him to examine traffic for passwords and other confidential data. An attacker could also point clients to a different name server, so when your machine looks up 401k-server.intranet.example.org, instead of connecting to the internal server, clients would be pointed to an attacker's machine. Denial of service attacks are also relatively easy if you use pools of IP addresses to assign to clients instead of static mapping. By requesting all available IP addresses, any legitimate client would be told that none are available, and would not be able to access the network. (Windows NT RAS servers are famous for doing this unintentionally.) The best way to catch these problems is to monitor your DHCP server log files and watch for suspicious activity. You should also plug in a laptop running UNIX so you can watch the log files as its DHCP request is handled. You can also avoid “address pool exhaustion” by using static mappings for clients; however, this can cause increased administration headaches. Most mail-related programs have a terrible history of root hacks. Sendmail used to be the poster child for insecure software, and most POP and IMAP servers have had at least one remote root hack. If possible, you should not allow POP and IMAP connections from outside your LAN, because usernames and passwords are sent in clear text. If remote users do require POP or IMAP access, you should SSL wrap it (“Crypto 101”, Sys Admin, May 2000). Another option is a Web-based email solution for remote users, which has the added benefit of being accessible from Internet kiosks. However, also creates another potential route to attack the mail server. Creating an “outside” mail server that proxies mail deliveries to and from your network can be effective in preventing many attacks. Using a “free” OS such as Linux, and the Postfix mail server (developed by Wietse Venema, author of many security software packages), you can effectively prevent attackers from connecting directly to a vulnerable mail server and exploiting it. Most mail exploits depend on old versions of software; if you keep up to date, you will be pretty safe. The other main attack comes from people trying to use your mail servers to send email (known as relaying) and is typically used by spammers to cheaply deliver bulk mail. Internet Most UNIX Internet servers are relatively secure. Apache, Zeus, and Roxen have excellent track records. Netscape had issues in the past, and is occasionally slow to issue fixes, but is a solid performer. It is relatively rare for the Web server to have a direct security problem. (It is usually a configuration issue, or a server-side program (CGI) that causes the problem.) In September 2000, a popular Web scripting language, PHP, was found to have a serious bug that allowed attackers to view files on the Web server. However, if you enabled SAFE_MODE under Apache, for example, it wasn't exploitable. Most Web servers have numerous safety features that are not enabled by default. If you have complex scripting and programming on your Web server, it is necessary to check the documentation for various techniques that can be used to decrease the risk. Most Web servers and Web programming languages also ship with many default test and example programs that are unecessar, or extremely dangerous. You can audit it manually, or use a scanner such as whisker to automate the task. ftp This is a service that is slowly waning in popularity, and a good thing too. Almost all ftp servers (even OpenBSD's ftp server) have had remote root hacks that in many cases are exploitable via anonymous ftp. One of the more popular servers, WuFTPD, has a terrible track record (literally dozens of remote root hacks) and is under semi-active development. ftp also sends and receives all usernames and passwords in clear text, making it easy for an attacker to sniff. If you must offer ftp services with individual user accounts and uploads (e.g., a Web-hosting company), your best bet is to use ProFTPD, which is relatively secure and has numerous security features. Be careful if you have any areas that can be uploaded to, especially by anonymous users, in case misconfigured attackers can use your site to distribute software, pornography, and so on. Overlap of ftp and WWW areas can be especially problematic -- http://www.apache.org/ was hacked due to a combination of poor systems administration and several minor software flaws. RPC RPC is a network protocol that is generally insecure, and enabled by default on most UNIX systems. Unfortunately, some operating systems, like Sun and IRIX, require it for numerous services. Because of the number of services that rely on RPC (such as, NFS, sadmin, rquota, rusers, spray, wall, rex, ufs, amiserv, etc.), it is almost impossible to disable it without the OS complaining. RPC relies on the remote machine's IP address as a form of identification; needless to say, this is very weak. Consider replacing RPC with Wietse Venema's rpcbind. SNMP SNMP is the titanic of protocols when it comes to security. The existing SNMP standards do not really have any meaningful security features, relying on a “community” name to authenticate services. Unfortunately, this community name is often left as the default “public”, and even when set to something else, it is sent in message headers. There is no authentication for senders or receivers of data. When buying SNMP-enabled devices, ask vendors about support for SNMPv3 (which has security features). Like RPC, the best solution is to upgrade to a secure version. Databases Databases is often an ignored area of security. Many databases ship with default passwords, including some that have administrative access. Make sure you verify that all built-in accounts are passworded correctly. The next largest problem is that developers are writing software that accesses the database, and giving the software far more access then it needs (e.g., the ability to make changes to system tables). When implementing software that accesses databases, scrutinize the level of access granted and reduce it to the minimum. Summary Most attackers will take the easiest approach with the least risk, which can lead to some interesting attacks. Even if you keep all your software up to date, replace insecure packages with secure packages, and restrict access, it is still possible for an attacker penetrate. There are many complex interactions within the OS between various software packages. Therefore, it is critical that your administrators communicate well because changes in one area can affect others. Links arachNIDS -- http://dev.whitehats.com/IDS/ Default password database -- http://www.securityparadigm.com/defaultpw.htm
Linux Security Knowledge Base -- HUNT-- http://www.cri.cz/kra/ rpcbind -- ftp://ftp.porcupine.org/pub/security/ SNMPv3 -- http://www.snmp.com/snmpv3/ snort -- http://www.snort.org/ whisker -- http://www.wiretrip.net/rfp/
About the Author
Kurt Seifried is senior analyst for SecurityPortal and somewhat confused as to what that actually means. His primary interests are security, crypto, privacy, and sushi. He may be reached at: seifried@securityportal.com.
|