From: Steve Friedl (steve@unixwiz.net)
Date: Tue Jan 13 2004 - 16:16:11 EST
On Tue, Jan 13, 2004 at 08:48:52PM +0100, Maarten wrote:
> I was wondering if any of you has experience in testing fax servers.
I'm the author of the oldest [1989], most popular commercial UNIX fax
system (VSI-FAX), and I can probably offer some thoughts. In general,
this is going to be a hard nut to crack, but it's not inconceivable.
Some notes in no particular order.
DISCLAIMER: I have not done anything with the ECM (error correcting)
modes, nor have I followed the fax spec in the last few years, so new
developments may have surpassed my experience. I'm also pretty much
limited to class 2 and class 3 fax modems, which have plenty of smarts.
Class 1 modems (where one must bang the low-level T.30 protocol) put
much higher burden on the driver and on the developer. I can talk
T.30, but haven't written to it.
*) Most fax modems also do data mode, so your best bet for getting
inside is to call with a regular data modem. Some systems, especially
those meant for small offices, will discriminate based on the answering
tone and spawn a getty/login when a data call arrives. These were
popular because a one-modem office can use the same modem for making
outbound fax calls while still giving data access to remote support
personnel.
Depending on how the data-call handoff is made, it's conceivable that
one can bypass some of the login process if the fax code tries to
handle it itself.
*) Getting "a regular shell" from a fax-only modem is going to be
damn near impossible: the fax protocols are all half duplex. I
also believe that once the modem is in fax mode, it's going to be
next to impossible to "fool" it into switching into data mode.
Unlike standard data connections, which pretty much just form a
conduit from the remote to the local computer (and the modem's
command channel is out of the way), a fax conversation is an ongoing
set of chitchat between the driver and the modem. If the modem
gets out of sync, somehow, it's going to fail the whole call.
*) There are three avenues for overflow that I can think of when all you
have is an external fax access:
FAX DATA
--------
Fax data are typically runlength encoded, and there are several flavors
(MH, MMH, 1D, 2D, etc.), but they are all binary patterns. I imagine
that sending a bogus codeword could get the fax decompressor out of
alignment, and if it's not paying attention, it could run off into
never-never land. This is unlikely because
a) many Class 2 fax modems do scanline validation on the fly, and ONLY
present valid data to the application. Bad scanlines are dropped,
sometimes with a note. No avenue there unless you can overflow
the *modem* code.
b) even with modems that don't do scanline validation (all Class 1 modems,
for instance), bad scanline data is a part of all fax conversations.
Unlike typical buffer overflows, which are almost never provoked
during "regular" operation, software which could not handle bad
scanline data would not live in the commercial market for more
than about three phone calls.
Fax engineers learn very early that the real world presents every
kind of bad data we could think of, and the T.4 decompressors are
shaken out very early, very aggressively, and very often. We learn
to add insane amounts of sanity checking to forestall this stuff.
TSI STRING
----------
During the initial setup of the call, both stations swap ID strings:
TSI - Transmitting Subscriber Identification
CSI - Called Subscriber Identification
The TSI is the caller, the CSI is the callee, and they are typically the
phone numbers involved. They are up to 20 characters long (enforced by
the encompasing T.30 protocol), and of a limited character set:
digits
space
"+"
But in practice, everybody allows full ASCII. Most commonly, server
software just sticks the received TSI into a buffer - and again, it
won't overflow because the limit is enforced by the modem on both
ends - but this string is sometimes passed around in the system later.
For instance, some fax systems provide for "notify scripts" that are
run when a fax is received. They're given information about the call,
including the filename of the (usually) TIFF file and the TSI string.
If this string is not sanitized, there are *all kinds* of shenanigans
that can be performed as this string is handed around to shell scripts.
I suppose it *might* be possible to roll your own TSI frame that tried
to send more than 20 characters, but this means you're writing your own
fax software.
NSF EXPLOITATION
----------------
During the initial part of a conversation, there is other data exchanged
besides the TSI and CSI, and this includes the NSF frames. These are
"Non-Standard Facilities", and they're used to allow machines made by
the same vendor to exchange data and perhaps enable some proprietary
modes. I believe that many of the newer fax modes (ECM, for instance)
started out as NSF-enabled facilities.
Unknown NSF frames are supposed to be ignored, and I think that most
computer-based fax software does use them. But if there *are* special
modes that can be enabled, these would be worth investigating because
it's an overflowable data channel if the data received is actually
processed.
CHARACTERIZING A FAX SERVER
---------------------------
I've never done this with security or pen-testing in mind, but there
is a lot that can be gathered remotely by paying attention during a
fax call. We routinely had to characterize a remote system that was
giving us trouble, and these things come to mind.
The order, timing, and format of the data received during the initial
part of the call can tell much. The NSF frame(s), if any, can reveal
the country and vendor of the unit, and proprietary data inside the
NSF frame can sometimes reveal other things (mailbox name, passwords,
and the like).
The "DIS" - Digital Information Signal - is particularly useful, as
it's a bitmask of many capabilities. Allowable modem rates, data
formats, encoding/error control modes, and the like are represented
in several dozen bits, and sometimes you can get a hint at what you
are looking at.
For instance, finding the minimum scanline time of zero means you're
probably talking to a computer, but >0 times mean it's probably an older
thermal fax.
I suppose that even before the fax handshake, one could pay attention
to the answer tones that fly by before the *fax* answer tone is heard:
the order and timing of these could also reveal what you're calling,
though I think you'd need specialized equipment to detect these.
--- I don't think I've ever heard of an externally exploitable fax server, though I've been out of the business for several years. Good luck, Steve --- Stephen J Friedl | Software Consultant | Tustin, CA | +1 714 544-6561 www.unixwiz.net | I speak for me only | KA8CMY | steve@unixwiz.net --------------------------------------------------------------------------- ----------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:45 EDT