Hacking the Web A Security Guide
by Anne Bilodeau
Interactivity brings risks. From funny pranks to malicious havoc, the damage that can be caused by hackers and crackers is worth your vigilance.
The Computer News Daily site was packing 'em in, drawing 60,000 hits a day. A 2,000-publication mother lode of technical information and columns, including regular writings by proto-hacker Bill Gates, New York Times-backed CND was one of the year's hottest launches on the Web. The site gave visitors lots of interactive options. Users could search the site's rich database, jump to other computer pages, or exchange views in the site's chat area.
Then some Unix hacker with spleen to vent decided to take the publishing giant down a peg. First, the site's server began to slow. Then it crawled. Then the system gummed up like an engine whose oil hadn't been changed for years, and just about stood still. Within a day, the rueful Webmasters running the site had to bring the server off-line, scrub it clean, and put in a new firewall.
The faceless bomber simply clogged the server with millions of copies of a mundane chat message, probably by attaching Unix commands to the chat area's overflow buffer, security experts say. This trick was a decade old when Morris brought the Net to a crawl with his infamous worm, but it still worked.
"This isn't genius hacking, just a simple program that was designed to fill up a server," said William Adler, a spokesman for the Information Services Group, which runs the site. Maybe so, but it had an impact. As of this writing, the chat area still isn't running, though Computer News Daily was back up in days.
Any network site can be hacked, security experts concede. But interactivity brings new risks. The chat areas, electronic commerce, and automatic e-mail response forms that make a site sizzle can also make it vulnerable, experts say. The easier it is for outsiders to talk directly to your server--to search for an order, review a membership list, or even fill out a form--the more you open the door to the bored, malicious, or criminally minded.
As Web sites transform simple cyberspace print ads to interactive feature-packed mini-online services, they become more attractive to outsiders: both the teenager on an idle vandalistic joyride, and the corporate criminal after the customer list on your Oracle database.
Expect hackers to try everything old Unix crackers did, plus a whole new range of hair-raising pranks, attacks, and old-fashioned theft. Invaders can yank your graphics and replace them with lurid cartoons, remove your password file, and dig into your internal databases. Hackers will try to slide into your internal network and post your financials on the Internet--and if they succeed, it will only be the most recent in a string of similar incidents.
"Why not singe the hairs of Net newcomers?", hackers ask. Old-timers haven't forgotten who used to be the boss of the electronic underground, and they aren't exactly fond of seeing corporate messages strewn across their once-private preserve. "Commercialism and pop culture threaten the structure and status quo of the Net," said one hacker via anonymous e-mail. "Moreover, hackers have never been treated well by the private sector and have a few axes to grind."
There's no magic bullet that will protect your site from every possible hack, of course. It's just that there has never been a better time to get your house in order, and what's more, defend yourself against the inevitable problems that will almost certainly occur. You may not even know when you've been invaded, and the break-in may be simply a once-over walkthrough by some bored college sophomore, but you should expect to be hacked, experts insist.
You can't afford to slam the interactive door shut; there's no question that Web users want sites to be a magic window into the company, not just a floating print ad. But if you open the door a bit, the malicious few will squeeze in. Like the eternal return of crabgrass to suburban lawns, pranksters, crashers, and the occasional serious criminal will inevitably keep scanning your site for weaknesses. In this article, we offer a few strategies to protect your site from the crackers' latest caprices.
What Are They After?
Ask around a hacker chat room, and they'll swear that cracking Web sites is mundane, a deadly bore. Sometimes it seems that half the folks who consider themselves "hackers"--clever meddlers with the intricacies of living code, not the antisocial destructors referred to as "crackers"--have gotten jobs as Webmasters or Internet developers themselves. Kind of like a bunch of Vietnam vets getting jobs coaching Oliver Stone movies.
But there's still resentment in the #hack channel in Internet Relay Chat, and a few angry people who'd love to show the corporate powers on the Net the door.
After the fall from grace of Phiber Optik, Kevin Mitnick, and other hacker demigods, it seems that many who might have the skills to conduct major break-ins expend their energy on pettier--but for a Web storefront owner more worrisome--experiments with their Unix skills.
There should be about 500,000 new Web sites up by the end of this year alone, according to projections by Seattle, Wash.-based Internet Solutions Inc. That figure should double to about 1 million by mid-1996, ISI said. Folks who might have put all of their energy into finding a back door into the Department of Defense now have their pick of visible, sometimes amateurishly set-up Web servers to rifle. Even if the files on the server for East Waukegan Shoe Sellers aren't too sexy, they're relatively easy to reach, and a ready opportunity for newer crackers to count coup in front of their peers.
"Mom and Pop's hardware store is just as interesting as Super-Mega-Corp if you just want to know how Unix works," said Chris Goggans, an Austin, Texas-based Internet security consultant and editor of "Phrack," an underground hacker magazine based on the Web.
"[Commercial] sites are easy targets, because many are small businesses who hear 'infobahn' and decide they want a Web site," agreed "Anonymous." "So they pull in a consultant and get him to set up a Solaris box and put pretty graphics on there. Unfortunately, they leave the box in a corner or perhaps add a dial-up so that their employees can write proposals out of it . . . ," leaving them nearly wide-open.
Of course, if the hacking community thinks your site is insulting, they'll be all over it. Witness the site that MGM/UA has set up to promote the recent movie Hackers whose movie-poster graphics were yanked, scribbled over with wiry hair and demon-neon eyes, and jammed back onto the server by members of the Internet Liberation Front. The site's developers tried reloading the original art, but the invaders kept replacing the front page, which included a few sentence promoting the movie, with grotesquely funny artwork and text lambasting the movie. The mutilated poster served as the convention poster for this year's DefCon, the ultimate hacker convention, whose bust-and-seizure-weary slogan is "Can you spot the Fed?"
What Can Happen?
Not all break-ins are catastrophic. In fact, a site administrator may not even know that an unauthorized presence passed through if they don't knock over the virtual chairs. Goggans, himself a high-profile Unix hacker known online as "Erik Bloodaxe," says that most server prowlers are likely to be relatively harmless, teenagers who wouldn't recognize hot business information if it bit them.
That's because many of the methods for breaking into Web servers are relatively simple, standard Unix hacks that have been around for nearly as long as there's been an Internet. The security holes can be head-slappingly obvious, but overlooked in a new business's eagerness to get started. One glaring example: Crackers may gain access because a site administrator didn't change the manufacturer's default passwords for the server. Anyone who uses the same machine will automatically know how to become superuser. User ID root and password root work far too often, note many experts. In other words, sites often haven't taken care of even the most obvious precautions, and that's what leaves them open to uninvited guests, not some elaborate scheme.
"By and large, you get into someone's system because they didn't lock the door," said Richard Ford of NCSA. "It's like coming up to a car and finding the door open, keys inside, and it's gassed up too." As a site become more interactive, more subtle but nonetheless well-known hacks are possible. Protocols like telnet, finger, and FTP have always opened up a server--and the networks attached to that server--to attack from outside. Forms have given unwelcome visitors yet more windows to pry and locks to pick. The increasing chatter between Web servers and browers like Netscape and Mosaic allows invaders to slide in unwelcome gifts like the New York Times' chat bug.
Typical firewalls don't always help, noted David Dalva of Glenwood, Maryland-based Trusted Information Systems in a paper last year. Some developers are considering writing the newer FTP server implementations and other protocols to include a HTTP server in the distributed code, allowing more efficient (and safe) access, but these projects are not finished yet, according to information on the W3 Consortium's site.
For the moment, most URLs support several resource types, including file, FTP, HTTP, gopher, WAIS, NNTP, mailto, telnet, and rlogin, while protective firewalls may permit only a subset of these resources to pass through the barrier. "Since Web servers provide these services independent of their normal mechanisms [independently of the normal FTP channels, for example], it is possible to bypass a firewall's security policy by using Web services," Dalva warned.
Root, Root, Root
Client software from godknowswhere zaps in. The user is talking to the root level on the Web server. It has to--a Web server has to run on port 80, and only root can attach to port 80. For a split second, at least, the user is the superuser, manipulating your machine. Yes, basic stuff--everybody who configures servers knows this.
What's often forgotten, experts say, is that if the attaching process isn't handled properly, a cracker can take control in nothing flat. Sysadmins or developers can write a routine that will switch the client immediately from root access to "nobody" with few permissions, but they don't typically do it.
A user who wants to break in can use this root access to get control of the machine, and perhaps gain access to the corporate network attached to the server. That can lead to splashy public relations disasters, as happened to General Electric. The electronics giant's face is still pink from last year, when crackers broke in through its Internet server and made data from its internal network public.
Once a user is inside the server, conducting standard activities such as entering data into forms, there is another world of harms that are at least possible. Invaders can do huge amounts of damage just by pushing the capability of forms or other protocols that provide a fixed buffer. Fill up the buffer in a form or chat area, add some assembly-level commands to the space after the buffer, and you can sometimes command the machine.
"The buffer overflow problem is the cause of 90 percent of all bugs in Internet software," said Dave Zuhn, an applications engineer with Roseville, Minnesota based Secure Computing Corp. "Once you overrun a fixed boundary, all bets are off. If you know what you're doing, you can get into the computer." Crackers can often exploit CGI scripts by overflowing a buffer. If they do gain access to the data channeled by the CGI script, they often end up with particularly sensitive proprietary information.
Imagine a form that collects customer data, and shunts the data to an Oracle database using a relatively simple script. The invading cracker will watch gleefully as the script taps into the database, and then gains access to the Oracle server as well.
The problem with CGI scripts, Zuhn said, is that they tend to be seen as a quick task to be run informally for the convenience of the programmer. "Most people who write CGI aren't defensive enough about their programming style to cope with all of the different ways information is handled."
Developing a Strategy
In sum, Web servers typically aren't very secure, experts say. But that's just because the people who configured the server haven't methodically worked through the obvious problems.
Consider each of the following issues when configuring your Web server, or conducting a security review, consultants and hackers advise. Some may seem insultingly obvious, but "it's amazing how often people haven't done the easy stuff," said one hacker.
- Develop an overall security strategy, not just a series of patches. The best approach to protecting your Web server is a "Defense in Depth," Zuhn warns. "It should not take a single bug to open up your entire system to the crackers," he says. "A server should be on a secured system, with enough security support to put up multiple fences between the cracker and the goodies." If a cracker must make use of three or more hard-to-exploit bugs to get through, that reduces the risk significantly, he notes.
- Consider using encrypted URLs for particularly secure sites, such as internal company files, suggests James Domengeaux of Houston, Tx-based Company. En-crypted URLs, a jumble of letters and numbers, look like meaningless line noise to human eyes, but actually contain both the address and the user's password. With an encrypted URL, the user can access only material made available to that particular password.
Encrypting a password into a URL does have one downside: If a user bookmarks that URL, and the bookmark file is stolen, the thief gains access to the protected site. Nonetheless, he says, encrypted URLs are still an improvement over ordinary named paths. "Encrypted URLs are another way to make things more difficult for hackers to get to, as they don't really know where they are going," Domengeaux says.
- Write your CGI script conservatively, giving users no chance to slip Unix commands directly into the server. For example, avoid passing arguments directly to a Unix command from a form. If your script passes an argument directly to a Unix command, "all I have to do is type a semicolon and start putting in other Unix commands," says Phrack's Goggans. "Some of the more popular Web form processing scripts are completely vulnerable to that". Any form that allows you to specify a recipient within the body of the form itself could lead to a break-in, he says. "You need to hard-code things into the Perl script . . . you never let the client determine where [the information] will go".
- Pay close attention to any ports that you feel are vulnerable, suggests David Cook, author of Launching a Business on the Web. Watchdog that port, looking for connect times that suggest a human rather than an automated user, he says. Then trace and track that possible prowler.
- Keep up with the latest patches and fixes to whatever server you run, all agree. This may seem like an obvious step, but far too many sites fail to take this elementary precaution. For example, there are a lot of NCSA httpd 1.3 servers out there, which are "very easy" to crack, Zuhn notes.
- If nothing else, close the gate as quickly as possible. Most experts warn that it's foolhardy to allow the server to run as root for any longer than necessary. Use a helper program, which doesn't take any input from the network, to handle binding to port 80. Using such a program, the server still runs as some user, usually "nobody," but not as root, taking away the cracker's golden opportunity to take control in an instant.
- Keep an eye out for developments like Domain and Type Enforcement(DTE) technology. Due in May 1996, DTE access control allows system administrators to categorize every file on a server according to its sensitivity. Some files may be protected from disclosure, and others from modification. If your server runs DTE, users won't be able to wander around the server reading directories. They'll be restricted to a set of permissions--a "domain"--appropriate to the "role" or "work identity" with which they log in.
During a session, all programs will be automatically restricted by DTE. Client programs can only read or modify file types appropriate to the domain, rather than the free-for-all that a cracked site has often yielded before. Even if a cracker logs on and unleashes malicious code, viruses, or programming bugs, he or she can only affect files at the given access level. Automatic processes that run in the background are also restricted, making it even harder for crackers to slide through the cracks.
For the moment, most hackers agree, there are far more challenging things to do than crack your Web site. An America Online break-in could bring a cracker long-lived fame, while a prowl through a florist's Unix box may evoke a yawn. But don't wait for the fashion to change, or the flow of electronic commerce to attract the attention of prowlers. You may not notice a problem until it's too late.
Anne Bilodeau is a Rockville, MD-based journalist specializing in technology and business coverage. She is the international financial desk editor with UPI's Washington, D.C. office. She can be reached at firstname.lastname@example.org.