Web-Site Security Failures
What's Happening Out There?
By Jay Heiser
The last 12 months have seen some dramatic Web-server security failures. While it should come as no surprise that high-visibility organizations like Microsoft and the Central Intelligence Agency attract digital vandalism, many relatively humble Web sites have also been targeted. It's interesting to read about the sophisticated, high-tech attacks, but most are really pretty boring -- unless your site happens to get hacked.
Mission-Critical ftp and Web Server
About a month ago, I received a call from a small software vendor that uses an Internet server to provide its product data on the Web. The company sells and updates its software with ftp. Someone had broken into the server, installed a chat server, and was using it to host a virtual party. The company tried to delete the IRC server and what seemed to be the hacker's access point, but he was able to get back in and retaliate by modifying the company's ftp server and Web-server configuration so that the servers would not restart. I was called in for advice.
After the second break-in, before calling my company, they had performed three important steps:
- They disconnected their server from the Internet.
- They made a complete backup of the server before experimenting with it again.
- They called the FBI.
The third step might seem extreme, but the software vendor was suspicious of foreign competition, and the FBI has been very diligent in tracking down digital intruders.
The company's server was running one of the semicommercial UNIX variants. The system had to be considered permanently compromised after the attack, so it would need to be remade from scratch, but I offered to look at it anyway to learn more about the attack. The company wanted to move on quickly and rebuild with NT. Before the hack, their Internet connectivity was fairly limited, so they decided to protect their Web server and simultaneously connect their LAN to the Internet through a firewall. We installed a WatchGuard firewall from Watchguard Technologies, a combined hardware and software package that can be configured and maintained without a lot of time or expertise. We put the Web server on a third Ethernet adapter, which allowed the firewall to protect it from many forms of Internet attacks, including syn floods.
A Springboard Attack
By the time the administrators of the Web-hosting site were aware of the hacker, he had already used the site as a springboard to compromise at least a dozen other sites. Another Web-hosting service had called to complain that they'd been hacked by someone coming from the Web-hosting site. Both sites were running BSDI UNIX, which is popular on Web farms. Unfortunately, it included a bug in the print service, lpr, that allowed anyone with a command prompt to gain root access. Once the hacker had root privileges on a UNIX server, he installed sniffer software and used it to monitor all network traffic for login and password combinations. The developers, creative staff, and even some of the sales reps at the hosting service had access to accounts at other Internet sites and regularly logged into them from their office. Each time they logged into another system, the hacker gained all the information he needed to log into the account himself.
The hacker probably could have stayed active on this site for quite a while, but the second site was administered by an experienced UNIX professional who regularly monitored the internal consistency of his machines, and quickly became aware of the unauthorized visitor. The hacker had taken advantage of the recently publicized lpr bug and was logging into his site from the first site. He had logged into the first site using one of several customers' accounts that allowed telnet access, and he was logged into that site from a host in Yugoslavia, making him very difficult to trace.
The first Web farm contacted our office for assistance in cleaning up and preventing further incidents. While the administrator applied an lpr patch to all of his systems, I logged into one of the hacked ones to see what I could learn. I first looked for back doors. Using the UNIX find utility, it took less than five minutes to discover several copies of the Bourne shell, sh, that had been squirreled away by a previous administrator and configured so that they would run as root. Anyone with a shell prompt could immediately gain root access on this system, even without the bugs! I logged in as root myself and sent the administrator a message. Without having seen the initial attack in progress, it wasn't possible to know how the hacker originally compromised the system, but either a back door or the lpr bug could have been used. Both of these were immediately fixed, but that was not a guarantee that the systems did not have some other unknown vulnerability.
While I was still logged in, the hacker actually reappeared. I told the administrator to try to talk to him and see what he could learn. He used the talk command to say "Hi'' to the hacker, who immediately responded. After some small talk, the administrator typed "OK, you got us, how'd you do it?" Frequently, hackers will brag about their accomplishments, but this one refused to provide us with any information.
Although the hosting service was unwilling to follow our strongest advice to remake all their systems from scratch (a reluctance shared by virtually all system administrators), they did follow our advice on hardening their systems. Most importantly, they hired an experienced UNIX administrator and separated responsibility for the operating systems from other Web-hosting duties. After ensuring that the software was up to the latest revision levels, the few users who were allowed to telnet in from the outside were informed that this would no longer be possible. Although
TCP Wrapper had been installed on the systems, it was allowing most Internet traffic to still come through. On our advice, it was configured to allow only http and ftp from IP addresses outside of the LAN. Although IP spoofing is rare, the routers were configured to disallow any packets that used IP header options. The site has continued to increase the sophistication of its monitoring devices and to reduce the number of network daemons running. It's inevitable that a large Web farm like this will always attract attackers, but the increased vigilance and commitment to security procedures have prevented further incidents thus far. (See "
Figure 1".)
Do You Really Need ftp?
While still under construction, a BSDI Web server was hacked through ftp, which was enabled to allow the page developers to upload files. The plan had been to configure ftp more securely after the site was up and running, but one of the test users wanted to demonstrate how sloppy the administration was. While this turned into a very embarrassing incident for the site administration, they were lucky that the hack didn't come from some other source. Not only did they allow ftp users to wander the system at will, but a bug in the user-administration utility changed the permissions on /etc/group, making it writable. It was simple for the intruder to upload a new /etc/group file that put him into group "wheel," which effectively gave him root access.
We had several recommendations. First, given that ftp was a requirement, it was imperative that users be contained within a controlled environment -- preferably their home directories. The system manager was able to configure WU-FTP to route incoming ftp sessions to the individual user's home directory, effectively limiting the damage from a compromised ftp password to a single user's directory. It's important to monitor the integrity of the system files, and the administrator normally uses the /etc/security utility, which reports on changes in security-relevant system files. It was actually running in this case, but because the machine was still under construction, the security reports were lengthier than usual, and they were not being reviewed. As always, we advised them to shut off all unused network services, and to use an access-control mechanism (TCP Wrapper or a firewall) to prevent outsiders from accessing services like telnet that are required for system administration.
We Join the Fun
One of the best ways to learn what vulnerabilities your system has is to hire a specialist to perform a penetration test. In other words, you pay someone to hack into your system. A financial institution in the process of upgrading its Web presence hired us to take a whack at its Web server. The site, hosted by a well-known Web-hosting firm, lasted about two hours before our technician cracked it.
First, we checked the system for vulnerabilities using Internet Security System's Internet Scanner. The scanner itself does not crack systems; it provides a list of running services and apparent vulnerabilities that suggest areas in which to begin the manual penetration test.
By methodically attempting to exploit known vulnerabilities, we were able to discover a number of holes. Taken together, they allowed us to gain total control of the machine. The most significant vulnerability was the PHF bug. Widely recognized as a problem since early 1996, the buggy code was included with the popular NCSA and Apache Web servers. It allows the execution of a command line running as the user that invoked the Web server, which is often root. This vulnerability alone is often enough to gain root access to a Web server, but this server's httpd was not running SUID root. This server allowed NFS access from the Internet, provided us with a compiler, and had an exploitable bug in rdist.
Attacks on both the CIA and the Department of Justice (DOJ) Web sites in Fall 1996 apparently exploited this same PHF bug. Without first-hand knowledge of the site configuration, we can only speculate, but the Webmaster probably underestimated the value of organizational information to those who have the wherewithal to attack it. In security-oriented organizations, information is carefully identified and appropriately handled based on its level of sensitivity. The information on the CIA and DOJ public-relations Web servers was clearly unclassified and suitable for public access, so little priority was placed on protecting it. But while the confidentiality (secrecy) of the data was not an issue, its integrity turned out to be incredibly important. Because high-visibility Internet sites tend to attract attack, their administrators should prepare for the worst.
Denial of Service Attacks
An Internet denial-of-service (DoS) attack is a way to prevent access to or usability of a system by exploiting characteristics of the network protocol and its system implementation. A syn flood attack, for example, consists of an endless series of connection requests. The host system receiving them acknowledges each one and then waits for the initiating system to respond to each acknowledgment, but this never happens. The responding host normally has data structures available to support only 255 connection requests, so an influx of bogus connection requests prevents it from processing legitimate requests. Barraging a host with connection requests at a rate faster than the timeout setting expires them and renders it unavailable for incoming traffic.
Virtually all TCP/IP based products are vulnerable to DoS attacks, but Microsoft products were especially exploited this summer. For example, the Out of Band (OOB) or WINNUKE attack is unique to Microsoft operating systems. Taking advantage of a little-used TCP packet-header option incorrectly implemented in Microsoft's TCP/IP stack allows anyone to remotely crash an unpatched NT 4.0 system using a simple utility. NT sites should be upgraded to Microsoft's latest Service Pack (SP3 at the time of this writing). Another example is Internet Information Server, which can be disabled through a particularly long URL and exploited using various hacker utilities. Again, IIS administrators should make sure that they are up to date with the latest patches.
DoS attacks are difficult to trace and probably cannot be completely eliminated. Most operating systems and devices using TCP/IP have been upgraded in the past year to resist the more common attacks, and a good firewall can resist known DoS attacks.
Conclusion
Why are Web servers failing? Because they are highly vulnerable and often improperly administered. Buggy software is the source of a security hole, but once a bug fix is available, its continued existence on a server becomes the fault of the administrator. While developing an appropriate security architecture for a complex electronic-commerce server is no trivial task, there is no excuse for fielding a Web server with known vulnerabilities. For simple http service, either UNIX or NT can be made very secure with a minimum of effort.
The more services running on your Web server, and the more executables in your cgi-bin directory, the more likely the system is to be compromised. The more well-known or controversial your organization, the more likely it is to attract hostile attention, but any server will eventually be discovered, poked and prodded by hackers. It's easy to prevent most attacks just by following the suggestions on the Web security and operating-system security FAQs and by following the Computer Emergency Response Team advisories where most of the problems in this article are first mentioned. I guarantee that your organization will find the resources to secure your Web server after an attack -- spare yourself the grief and take the time to secure now.
Jay is an experienced security consultant who has been building Web servers since 1993. He writes a monthly security article for Java Developer's Journal. He can be reached at jayh@mindspring.com.
Previous Page |
1
|
2
|
3
Next Page
