NEWS AT SEI
This article was originally published in News at SEI on: March 1, 2002
The answer to almost any question is probably on the Internet, but there can be risks in going after it. By posting a query to a newsgroup, for example, you can provide enough information to an intruder to give him or her strong leads for mounting an attack on your system. Having an awareness of the kinds of data that intruders can capture and use in perpetrating attacks will help you stay on friendly terms with the Net.
When I was growing up back in the late 1950s and early 1960s, our local grocery store sold Funk & Wagnalls encyclopedias, and they gave discounts based on the amount of groceries that you purchased. It took our family a long time, but we eventually became the proud owners of our own set of green Funk and Wagnalls. In those days, having your own encyclopedias was one of the few ways to acquire information, especially the kind we needed to write reports for school. Plus, they were convenient. If you had them at home, you didn't have to bother your parents to take you to the library to do your research.
“It’s On the Internet”
Now the world is vastly different. No matter what the question is,it seems that the answer is “It’s on the Internet.” Long gone are the Funk & Wagnalls, or anything similar for that matter, from the grocery store. (In fact, Funk & Wagnalls New Encyclopedia is now available on CD-ROM for your computer.) As the Internet spreads to more and more households, information that you were once able to buy or receive in the mail—store catalogues come to mind—will be available on the Internet, perhaps only on the Internet. If you are on the Internet from your home, you have instant access, especially if you have a cable modem or a DSL connection. The world is at your fingertips!
People are also instantaneously accessible, as are archives of discussions on various topics. You can send a message to anyone with an email address; and if that message goes to a discussion list, more than likely it will be archived and indexed so that others can benefit. Again, no matter what the question, the answer is probably on the Internet somewhere. Even finding those answers is less of a challenge than it was a few years ago. There are many indexing engines that sweep the Internet and capture what is needed to allow you to search the myriad of sites that are connected. The information is out there for the taking, and it is becoming easy to find.
But risks go along with this convenience—for home and commercial users alike. Imagine, then, that you are a systems administrator and you are having some trouble with a piece of technology, say the integration of a shopping-cart application with your Web server under an operating system. The Internet to the rescue. You peruse the related vendor-support Web pages and, failing to find just what you are looking for, you begin to search the appropriate news groups and archives of email discussion lists. You find some items that are close to your problem and that match your configuration, but not exactly. To make sure you have the right set of circumstances and problem solution, you decide to post the following to a news group:
From: Joe Sys-Admin <joeSA@FledglingEcommerceStartup.com>
Date: Mon, 2 Apr 2001 10:08:48 -0600
Subject: Grelnob’s Shopping Cart App on MacroHard’s SSI Server
Dear Fellow Systems Administrators:
I’m trying to install Grelnob’s Shopping Cart Application, Version The.One.With.Bugs, under MacroHard’s SSI Server, Version The.One.With.Bugs, on a FarmerInThe platform with 2 processors, 256Mb of memory, and 20Gb of disk. The error I am getting is:
Cannot find application library
But I know that I have it installed in the same location as the SSI Server. Anybody else have this problem? Please drop me a line or give me a call at 1-800-555-1212. TIA!
This certainly seems harmless, doesn’t it?
Consider this: you are an intruder and you have selected Fledgling Ecommerce Startup as your next target. Normally, you need to do an amount of reconnaissance of your target before you attempt a break-in. This message from Joe is a gold mine of information, saving you potentially several weeks of work. Let’s see what could be learned from this message alone:
- That in the domain named FledglingEcommerceStartup.com, there is an account named joeSA. Now all you need is a password, and you may be able to log in to one of their machines. You are half-way home.
- That the machine used to send this mail is in the Central time zone (-0600 or 6 hours west of Greenwich Mean Time), so now you have an idea of the working hours of the staff—when people are likely to be in and out of the office.
- The software configuration and version of two key components of Fledgling Ecommerce Startup’s business, namely Grelnob’s Shopping Cart application and MacroHard’s SSI Web server.
- The hardware configuration of one of their servers.
- The telephone exchange that you could use in a war dialer (automated dialing) attack.
Wow! That’s a lot of information “leaked” to the world at large, and all in the name of solving a simple problem. And, there’s probably more information encapsulated in the Receivedand Message-IDheaders that are not shown in this example. A gold mine indeed! To learn even more about your target, you could search the archives of various news groups and discussion lists to see if old Joe or anyone else from FledglingEcommerceStartup has posted questions. This may give more clues about hardware and software configurations and other accounts that may be available to you when trying to gain access. You could even build on what you already know by sending Joe a response to his question. You’ll get more information from his inevitable response. Reconnaissance comes in many flavors.
What should Joe have done? The key point is connecting the configuration information with an email address and, therefore, with a specific site. By breaking this relationship, Joe could have asked these same questions and still gotten the information he needed to solve his problem without leaking extraneous information. One way to achieve this is by using another email site like hotmail.com or lycos.com, for example, and not Joe’s production site. Unfortunately, the telephone number is a bad idea no matter what the source of the email. Sorry, Joe, but the Information Superhighway is littered with potholes.
The Internet is indeed your friend and can significantly speed the flow of information that you need to solve problems when building cost-effective and secure configurations. However, there is a cost, and frequently that cost is difficult to recognize, let alone quantify. That’s what makes it your foe.
The message here is that virtually every time you access another computer on the Internet, whether from work or home, you are leaking information. Be aware of what is happening and seek ways to minimize the information that you provide. You never know who’s watching. Now, where’s my old Funk and Wagnalls?
About the Author
Lawrence R. Rogersis a senior member of the technical staff in the Networked Systems Survivability Program at the Software Engineering Institute (SEI). The CERT Coordination Center is a part of this program. Rogers’s primary focus is analyzing system and network vulnerabilities and helping to transition security technology into production use. His professional interests are in the areas of the administering systems in a secure fashion and software tools and techniques for creating new systems being deployed on the Internet. Rogers also works as a trainer of system administrators, authoring and delivering courseware. Before joining the SEI, Rogers worked for 10 years at Princeton University. Rogers co-authored the Advanced Programmer’s Guide to UNIX Systems V with Rebecca Thomas and Jean Yates. He received a BS in systems analysis from Miami University in 1976 and an MA in computer engineering in 1978 from Case Western Reserve University.
This and other columns by Larry Rogers, along with extensive information about computer and network security, can be found at http://www.cert.org.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.