Vulnerability Development mailing list archives

Timbuktu32


From: BlueBoar () THIEVCO COM (Blue Boar)
Date: Mon, 4 Oct 1999 22:07:42 -0700


Here's a few bits of weirdness I've noticed with Timbuktu.  For those who
don't know, Timbuktu is a remote control application like PCAnywhere,
CarbonCopy, etc..  It start out on the Mac platform, and is actually
cross-platform Mac & Windows, which IMHO is it's main standout feature.
Later versions also include file transfer, chat, & observation mode in
addition to control mode, plus probably a few other features I haven't paid
attention to.

I wouldn't say it has any stealth mode, at least not that I'm aware of.  It
takes control of the main desktop, so is generally apparent if you're
sitting in front of the machine.  It keeps logs of people who have
connected, locally on the server machine.  It should be pretty trivial to
erase the logs if desired.

I first started to examine TB2 at work, where it's part of a standard
template that goes on almost all PCs.  Someone sent an internal email
noting that the passwords would show up.  I.e. if someone had connected to
your machine, and you pulled up the app after, there was their password
showing in the clear.  Whoops.  This is a problem because it's intended for
IT personnel to control user's machines, and users aren't supposed to have
the passwords.  I think it was build 635 that did this.

This also means that either the passwords stored locally, or the passwords
across the wire are decryptable/decodable.  I've sniffed the connections,
and the passwords are not in the clear.

Passwords are stored locally in tb2.plu.  I've done some brief looking at
the file.  There is a small password history, passwords are at least
encoded.  Account names are in the clear.  In my environment, all users
have the same passwords.  So, if any user cracks a password, they have
access to all machines.  There is also a master password of sorts that the
users can't erase via the GUI.  This was done as part of a corporate
install setup, so I believe all of this customization is an intended
feature.  There is also a way for NT TB2 servers to authenticate against
the SAM, which I think will probably be safer.

While sniffing connections, I've noticed that TB2 gives a lot of useful
information.  It gives company name, and I think machine name and a few
other things.  I'll post samples, and a simple tool soon.

The authentication setup is UDP, and looks fully replayable, though I'm not
sure you can sync the control connections that way.  This is how I figured
out how to elicit a response. (i.e. I've got a simple TB2 port scanner.)

I haven't looked for buffer overflows yet.  Though, TB2 crashes on me all
the time during normal usage, so I assume it's not very well designed.

I'm especially interested in folks helping me with the password decodes.
I'll post some sample stuff within the next few days.

At first glance, this looks broken enough that it should probably be ripped
out right away if you're using it.

                                                        BB


Current thread: