📄 ch23.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><HTML><HEAD> <TITLE>Maximum Security -- Ch 23 -- An Introduction to Breaching a Server Internally</TITLE></HEAD><BODY TEXT="#000000" BGCOLOR="#FFFFFF"><CENTER><H1><IMG SRC="../button/samsnet.gif" WIDTH="171" HEIGHT="66" ALIGN="BOTTOM" BORDER="0"><BR><FONT COLOR="#000077">Maximum Security: </FONT></H1></CENTER><CENTER><H2><FONT COLOR="#000077">A Hacker's Guide to Protecting Your Internet Site and Network</FONT></H2></CENTER><CENTER><P><A HREF="../ch22/ch22.htm"><IMG SRC="../button/previous.gif" WIDTH="128" HEIGHT="28"ALIGN="BOTTOM" ALT="Previous chapter" BORDER="0"></A><A HREF="../ch24/ch24.htm"><IMGSRC="../button/next.gif" WIDTH="128" HEIGHT="28" ALIGN="BOTTOM" ALT="Next chapter"BORDER="0"></A><A HREF="../index.htm"><IMG SRC="../button/contents.gif" WIDTH="128"HEIGHT="28" ALIGN="BOTTOM" ALT="Contents" BORDER="0"></A> <HR></CENTER><CENTER><H1><FONT COLOR="#000077">23</FONT></H1></CENTER><CENTER><H1><FONT COLOR="#000077">An Introduction to Breaching a Server Internally</FONT></H1></CENTER><P>This chapter briefly discusses the internal breach. An <I>internal breach</I>can be defined as any breach of security on a network to which the hacker or crackerhas some access, on which he is a user with a valid account, or where he is a memberof a company that maintains such a network.</P><P>Whether you are a victim or a perpetrator of an internal breach, know this: Authorizedusers have access to an enormous amount of information that remote (and unauthorized)users and crackers work hard to acquire. For example, building a list of users ona UNIX system is only a few keystrokes away for the authorized user. It can be doneas simply as this:</P><PRE><FONT COLOR="#0066FF">ypcat passwd || cat /etc/passwd) | sed -e `s/:.*//'</FONT></PRE><P>Compare this with building a reliable username list from the outside. This mightentail writing a script that routinely issues <TT>finger</TT> and <TT>ruser</TT>requests, checks the data against an outfile, and discards dupes. Even if the networkyou are targeting is small, you could spend a lot of time trying to obtain a decentlist. In contrast, larger networks such as ISPs might render hundreds of names ata time. It depends on how lazy the system administrator is at that location. As Idiscuss in Chapter 13, "Techniques to Hide One's Identity," if the systemadministrator has failed to install a hacked finger daemon or failed to restrictfinger access either marginally or completely, a huge user list can be obtained witha single command line. So my first point is this: Local users who have even limitedbut authorized access can obtain quite a bit of information about users.</P><P>Additionally, they have access to tools that are unavailable to remote, unauthorizedusers. Exactly what those tools are depends on the system; but in most UNIX-basedenvironments, this includes at least shell language access and probably Perl access.If the network in question is an ISP, it probably also includes access to a C compiler.If that ISP is running Linux, there is a strong chance that a laundry list of compilersis available. Most system administrators who use Linux install the majority of, ifnot all, development packages. Certainly, TCL will be available. This will probablybe accompanied by gcc and g++, a BASIC development package, and perhaps Pascal, Python,FORTRAN, and others. Aren't Linux and GNU wonderful?</P><P>Nevertheless, the shell languages alone are enough. These, coupled with awk andsed, formulate a formidable programming environment. And this doesn't apply exclusivelyto UNIX, either. Here are some power-packed development tools that could empowera user on other networks or platforms:<UL> <LI>C and C++ <LI>Qbasic, BASIC, or VB <LI>Envelop <LI>Pascal <LI>Assembly <LI>Perl</UL><P>In fact, user access to programming tools is an even more critical issue in theWindows 95 environment. NT, providing it is installed correctly, boasts strong accesscontrol. This control is at least as strong as in most implementations of non-trustedUNIX. In contrast, Windows 95 has no access control.</P><P>Because of this, a local user can install such development packages on his workstationat any time. Most of these tools now exist in free form, either from GNU or someother organization or vendor. There are even TCL interpreters for Windows 95, sothe user need not spend $400 for a development package. Contrast this with the UNIXand NT environments. A local user installing such packages on a local workstationhas serious problems. For example, access control policies can prevent users fromexecuting programs in certain directories. Also, disk quotas are often institutedon such networks. Thus, a user only gets (for example) 8MB of space for himself.This precludes all but the smallest compilers, and even then, installation is tricky.</P><P>Conversely, a user can install anything he likes on a Windows 95 network; however,he probably doesn't even have to. If a full distribution of Office is available andno third-party access-control product has been installed, the local user will atleast have access to WordBasic or other tools that, while not generally characterizedas full-fledged development tools, can offer increased levels of access and control.Let's not even <I>consider</I> the possibilities if Java is available.</P><P>Moreover, local users have an immediate avenue to the network. They are thereforeprime candidates to place a sniffer on the drive or drives. As discussed in earlierchapters, this allows them to obtain (at the very least) the usernames and passwordsof those located on the same network segment.</P><P>There are other advantages of being a local user. One is simply that you are authorizedto be there. Think of this not in terms of computers but in terms of real life. Anindividual who is about to commit a burglary late at night is already in a compromisedposition. If he is found loitering about the grounds of a local resident's home,he already appears suspicious. However, if he lives inside the house as a guest,he has every right to be lurking about at 3:00 a.m.</P><P>Similarly, a local user with authorized access (who intends to exceed that access)is supposed to be there. Although it might seem odd for someone to be logged on inthe middle of the night, normal user activity during the day is perfectly acceptable.</P><P>With this right comes certain amenities. One is that the user's presence on thesystem need not be hurried. In contrast, a cracker who tries to leverage the simpleaccess he has gained may be forced to spend only short periods on the network. Untilhe gains root (or a reasonably facsimile thereof), he is constantly under pressureand the threat of being discovered. In contrast, a local, authorized user can crackat his leisure. He need not hurry at all. In fact, he could spread his activity overa period of months.</P><P>Furthermore, local users have the ability to use perfectly innocuous techniques(that in themselves cannot be deemed unauthorized) to derive information about thesystem. A user can quietly run netstat, arp, ifconfig, and other queries withoutanyone thinking twice. Therefore, he has the luxury of building an enormous knowledgebase about the system using techniques that will likely never be logged. The systemadministrator who ends up investigating a breach that started this way can only hopethat some of these queries were redirected to outfiles or hope for other tangibleevidence.</P><P>That said, being a local user does have its disadvantages. For instance, crackingunder an authorized account places the user in a compromised position if troubledoes eventually surface; the system administrator can easily determine who has beendoing the cracking. If the cracker is unaware that his activity has been detected(and the system administrator has been logging that activity), he is basically upthe creek without a paddle. Subsequent testimony of co- workers can at least establishthat this user was sitting at that desk all day long.</P><P>Moreover, the local user is under a lot of pressure to avoid leaving materialsor evidence behind. The remote user needn't worry about this. For example, a remoteuser can issue a finger query from his local prompt and redirect the informationto a file. No one will be scanning the remote user's directories for such files.In contrast, the local user cannot safely leave that information on the drive. Infact, if the situation is sufficiently serious, the local user shouldn't place theinformation on the drive at all, even if he intends to delete it later. Data recoverytechniques are now sufficiently advanced that if the local user discards or otherwisedeletes the information, it can probably be recovered. In such an instance, the smartlocal cracker will at least encrypt the data before discarding it. However, thismay even be a wasted effort, depending on the operating system, the version, thetype of file, and so forth.<BLOCKQUOTE> <P><HR><FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Ever heard of MicroZap? If not, you should become familiar with it. It is a utility that will obliterate trace elements of files that have been (or are about to be) deleted. You can get information on this utility online at <A HREF="http://www.govtech.net/"><TT>http://www.govtech.net/</TT></A>. <HR></BLOCKQUOTE><P>For an interesting (albeit brief) look into this problem, I suggest you read thearticle "Erased Files Often Aren't," by Michael Anderson. In it, he reportshow he received some floppy disks from a consortium of executives in law enforcement.He wrote:<DL> <DD>As you can surmise, curiosity killed the cat and I put on my forensic computer science hat and took a `forensic peek' at the diskettes. That brief examination revealed the diskettes had been sanitized and the files on all of the diskettes had been "erased" using standard DOS commands. The recovery of the erased files took just a few minutes and the content of the actual files dealt with information that would not be considered sensitive. However, my further examination of the diskettes revealed quite a bit of sensitive data which had been written to the file slack associated with the erased files.</DL><BLOCKQUOTE> <P><HR><FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>You can find "Erased Files Often Aren't," by Michael Anderson (published in <I>Government Technology Magazine</I>, January, 1997) online at <A HREF="http://www.govtech.net/1997/gt/jan/jan-justice&technology2/jan-justice&technology2.shtm"><TT>http://www.govtech.net/1997/gt/jan/jan-justice&technology2/jan-justice&technology2.shtm</TT></A>. <HR></BLOCKQUOTE><P>Perhaps crackers reading this aren't thoroughly convinced; perhaps that examplewas a bit too benign. What about this case, then:<DL> <DD>The employees had been using the company's software illegally to manufacture and market products based on the employer's proprietary program. In an attempt to hide traces of their wrongdoing, the employees reformatted the hard drives on their PCs before leaving their employment. The company knew that some of the information on the drives might contain the electronic trail that they needed to stop the illegal use of their intellectual property. They sent the drives to Ontrack's lab in Minneapolis, MN, where the data was reconstructed, leading them to contact outside counsel to pursue action against the former employees.</DL><BLOCKQUOTE> <P><HR><FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The previous paragraph is excerpted from an article by Richard K. Moher titled "Computer Crime: Tips on Securing and Recovering Electronic Data" (originally published by New York Law Publishing Company). This article can be found online at <A HREF="http://www.ljextra.com/securitynet/articles/121796s2.html"><TT>http://www.ljextra.com/securitynet/articles/121796s2.html</TT></A>. <HR></BLOCKQUOTE><H2><FONT COLOR="#000077"><B>Anatomy of a Local Crack</B></FONT></H2><P>At the beginning of this book, I discussed the types of holes that exist, whythey exist, and what impact they can have on Internet security. If you remember,I pointed out that local holes were far and away more common than remote ones.</P><P>Remote holes are matters of extreme concern. In fact, when a remote hole surfaces,crackers have to work to capitalize on that hole within the first few days of itsreporting. If they fail to do so, the hole will be swiftly closed, precluding furtherexploitation. Moreover, programmers are extremely careful when coding remote applications,⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -