Do you need a penetration test? We look at the use and abuse of penetration testing
February 1997
![[Next story]](/sunworldonline/icons/tb-next.gif){kind=icon}
![[Table of Contents]](/sunworldonline/icons/tb-toc.gif){kind=icon}
![[Search]](/sunworldonline/icons/tb-search.gif){kind=icon}
|
|
Do you need a penetration test? We look at the use and abuse of penetration testing |
February 1997
|
Even if your company has spent the requisite time and money to secure the data center or a specific facility, how can you be sure it really is secure? You can perform your own penetration test of the facility, or you can hire a consultant or firm to do it for you. This month's column includes the composition of a penetration test, its benefits and risks, and information on performing one yourself or hiring a company to do so.Also in Pete's Wicked World this month: the bookstore has a roundup of sites providing information about intellectual property on the Internet (and how to protect it). In the buglist, information on a serious bug in
wu-ftp. And, if you have Solaris security questions, visit the just-updated Pete's Security FAQ. (3,600 words)
 Mail this article to a friend |
How can these questions be answered satisfactorily? Through a penetration test. This test is usually performed by an outside agency that has teams dedicated to just this sort of work. The test could be performed by employees of your company, but one of the points of the test is to throw out all assumptions. Consider how many times you've told yourself (as a security officer at your company) "Well, that machine's patches are out of date" or "I wonder how Bill configured that system"? Although insiders are one of the best sources of information about the state of security within a facility, sometimes it takes an outsider, or a security expert at your company who is not involved with the facility, to rationally analyze the security.
Because penetration testing can be useful in the right setting when executed in the right way, this month's column looks at the details of the who, when, why, and how's of penetration testing.
Unfortunately, if you run to your bookshelf to read all about these site inspections chances are you won't find much. A search of all the security books in my library found just one paragraph on the topic.
What goes into penetration testing?
Why all the secrecy about penetration testing?
Penetration test teams evaluate one or more of these aspects of your site:
The methodology used may vary, but a penetration test usually consists of four steps:
Within these four steps, various methods can be used to aid in the testing. For instance, social engineering could be used for information gathering, or it could be used to decide that no social-engineering attacks should be attempted. Also, various software and hardware tools can be used.
SAIC, a company that does penetration testing and more, recently completed an evaluation of a secure banking site that I implemented. They were kind enough to share a list of some of the software tools they have available for their testing. Check the Penetration Tools sidebar.
What are the drawbacks to testing?
Of course, there is a down side to penetration testing.
The net result of a penetration test is a report that spells out what was done and what was found. This report will go through multiple revisions as the testees respond and the testers modify and generate a new report. Don't underestimate the time that this cycle takes. If you have a facility that is "going live" at a fixed date, be sure to plan for adequate testing time.
Notice that all testing begins at the beginning -- with your site security policy. If you don't have a policy to implement, it is very difficult to tell if you're meeting your security policy goals. It is even more difficult for an external testing team to evaluate your site. They could point out all the weakness of your site, but this list can be quite extensive even at relatively secure sites. Rather, they want to compare the state of your site with your goal to determine the differences. In this way they can concentrate on the security aspects that are important to your company (e.g., the security of a Web server).
For more reading on penetration testing, check the Concept Five web site, and the information provided by US Host about the testing they perform.
Bug of the Month Club
It's painful when a program you know and love develops a large
security hole. This just happened with wu-ftp. Because
the only good coverage has only been in the best-of-security mailing
list (see the
FAQ
for more info), the full text of the message is
included here. If you run wu-ftp 2.4, beware. it was
also pointed out that the fix given below may not be sufficient. Wietse
Venema also reports a similar problem in his logdaemon
program, which is included in the newest version. Wietse also
speculates that all Unix FTP programs may have this bug, so again,
beware.
Subject: serious security bug in wu-ftpd v2.4
From: dg@root.com (David Greenman)
Summary
-------
There is a serious security bug in wu-ftpd v2.4 (including the
version from Academ) which may allow both regular and anonymous users
to access files as uid 0 (root). The same bug is also responsible for
an advisory lock not being unlocked -- potentially resulting in blocked
access to future ftp logins and filling up the process table and swap
space until the server dies.
Description
-----------
The ftpd server installs two signal handlers as part of its startup
procedure: one to catch SIGPIPE for control/data port connection closes,
and one to catch SIGURG for when out-of-band signaling is used with the
ABOR (abort file transfer) command. The SIGPIPE handler is:
lostconn(int sig)
{
if (debug)
syslog(LOG_DEBUG, "lost connection to %s [%s]", remotehost,
remoteaddr)
;
dologout(-1);
}
...which causes the ftpd server to exit via dologout() whenever the
control or data connection is unexpectedly closed. The function
dologout() is:
dologout(int status)
{
if (logged_in) {
(void) seteuid((uid_t) 0);
logwtmp(ttyline, "", "");
}
syslog(LOG_INFO, "FTP session closed");
if (xferlog)
close(xferlog);
acl_remove();
/* beware of flushing buffers after a SIGPIPE */
_exit(status);
}
...which changes the effective uid to 0, adds a logout record to wtmp,
closes the xferlog log file, removes this instance of the server from
the PID file for his class, and exits.
The initial part of the SIGURG handler is:
myoob(int sig)
{
char *cp;
/* only process if transfer occurring */
if (!transflag)
return;
cp = tmpline;
if (getline(cp, 7, stdin) == NULL) {
reply(221, "You could at least say goodbye.");
dologout(0);
}
upper(cp);
if (strcmp(cp, "ABOR\r\n") == 0) {
tmpline[0] = '\0';
reply(426, "Transfer aborted. Data connection closed.");
reply(226, "Abort successful");
longjmp(urgcatch, 1);
}
(...)
...which does nothing if transflag is 0 -- not currently doing a file
transfer, but if you are and an ABOR command was issued along with the
"urgent" data that caused this signal, then the procedure does a longjmp()
restoring the "urgcatch" saved state, which ultimately returns back to the
server main command loop.
Now, some FTP client programs will abort a file transfer by BOTH
closing the data connection AND issuing an ABOR with out-of-band
signaling.
In many instances, the ftpd server gets the SIGPIPE due to the closed data
connection and begins the dologout() procedure. While it is uid 0 and sometimes
while it also has the pid file advisory lock (which occurs in the acl_remove()
procedure), the ftpd server will sometimes be interrupted by the SIGURG that is
delivered as part of the ABOR command. Since transflag is not 0 (a file
transfer WAS occuring), the signal handler does a longjmp which ultimately
returns to the main command loop...and presto, you are uid 0, and to make
things even better, the xferlog log file is closed so nothing you do is even
logged.
A patch to fix this problem is simple:
*** ftpd.c.bak Wed Jan 1 22:10:05 1997
--- ftpd.c Wed Jan 1 22:10:14 1997
***************
*** 2503,2508 ****
--- 2503,2514 ----
void
dologout(int status)
{
+ /*
+ * Prevent reception of SIGURG from resulting in a resumption
+ * back to the main program loop.
+ */
+ transflag = 0;
+
if (logged_in) {
(void) seteuid((uid_t) 0);
logwtmp(ttyline, "", "");
...which does as the comment suggests.
-DG
David Greenman
Core-team/Principal Architect, The FreeBSD Project
The Bookstore
Are you reading this column from its
original source or from a copy? If you print out some pages from a
Web site and give them to a friend, are you violating copyright? How
about if you duplicate a Web site wholesale?
Copyright issues were considered to be mostly academic issues until computers and the Internet came along. Publication has grown from an ability of the few to a daily-occurance of the many. Along with the excitement (and abuse) of trivial publication have come a blurring of the legal lines. For instance, you can now sit at your home in Oshkosh and gamble in Jamaica. Intellectual property is also under attack by the new technology. It's now time for everyone involved in creating content and protecting content to become at least passingly-familiar with the law and how it effects computing and intellectual property. There are several Web sites that contain information of interest:
If you're looking for a very high-level overview of security concepts and solutions, check out www.securityinfo.com. It's a bit of a sales pitch (it's sponsored by a bunch of security and consulting companies), but it provides a good summary of security concerns.
While you're surfing the Web, you might want to check out a report about information warfare written by the Defense Science Board. This is a lengthy report concerning information warfare on a large scale, and how the defense department can take steps to combat it.
DataNet Security '97 is an interesting-looking conference about security on the Web. Might be worth a visit to Miami in February.
While you're considering security conferences, don't forget
SANS '97, surely one of the best bangs
for the buck around. It's in April in Baltimore.
|
|
Resources
|
|
|
|
![[(c) Copyright Web Publishing Inc., and IDG Communication company]](/sunworldonline/icons/b-copyright97.gif){kind=icon}
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-02-1997/swol-02-security.html
Last modified:
Tools used by SAIC when they perform penetration tests:
About the author
Peter Galvin is chief technologist for Corporate Technologies, Inc., a systems integrator and VAR. He is also adjunct system planner for the Computer Science Department at Brown University, a member of the board of directors of the Sun User Group, and has been program chair for the past four SUG/SunWorld conferences. As a consultant and trainer, he has given talks and tutorials world-wide on the topics of system administration and security. He has written articles for Byte and Advanced Systems (SunWorld) magazines, and the Superuser newsletter. Peter is coauthor of the best-selling Operating Systems Concepts textbook.
Reach Peter at peter.galvin@sunworld.com.