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:
- Timbuktu32 Blue Boar (Oct 04)
- <Possible follow-ups>
- Re: Timbuktu32 Robert G. Ferrell (Oct 05)