Home page logo
/

pen-test logo Penetration Testing mailing list archives

Re: potential fax server security issues?
From: Steve Friedl <steve () unixwiz net>
Date: Tue, 13 Jan 2004 13:16:11 -0800

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

---------------------------------------------------------------------------
----------------------------------------------------------------------------


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]