External Security Implications of Fax Servers

NOTE - this is an expanded version of posting to the penetration-testing mailing list (PEN-TEST) run by SecurityFocus, in response to this request:

> I was wondering if any of you has experience in testing fax servers.

I'm the author of one of the oldest [1989] and most popular commercial UNIX fax system (VSI-FAX, now sometimes called Esker Fax), and I can offer some thoughts (in no particular order). In general, this is going to be a hard nut to crack, but it's not inconceivable.

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 overtaken my experience. I'm also pretty much limited to class 2 and class 3 fax modems, which handle most of the low-level stuff automatically. Class one modems require host software to bit-bang the T.30 protocol and put a much higher demand on the driver and on the developer. I can talk T.30, but haven't really written to it.

Exploit data mode

Most fax modems also support data, and with software support, the fax server can also accept a data call and route it through a getty/login process. These arrangements were very popular with smaller offices because the same modem could be used for outbound fax while still being available for inbound data from vendor support personnel. With internet connectivity so common, this is less prevalent, but the modes remain.

Class 2 modems can be told how to answer incoming calls:

AT +FCLASS+2; +FAA=0 - answer as fax only
AT +FCLASS+0; +FAA=0 - answer as data only
AT +FCLASS+2; +FAA=1 - auto answer

When the modem actually answers the call, it tells the host what was ultimately negotiated with the first response. If it's the word CARRIER - possibly followed by a speed or modulation token - then this is a data call, but otherwise the responses are a series of tokens starting with +F. These are fax calls.

By far the best avenue for getting into a system remotely is to find the data mode, because this is a more "traditional" form of entry. In addition to the usual techniques for gaining remote modem access, there may be some additional avenues due to how the fax software hands off the call.

"Login processing" is much harder to get right than simply prompting for a username and a password - there are many fine details required in order to not be fooled by overflows and the like. A responsible fax server will invoke the underlying system's getty or login programs, but a server that tries to "roll its own" processing is more likely to have unfound bugs.

Look for potential buffer overflows

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 host and the modem. If the modem gets out of sync - for whatever reason - it's simply going to fail the whole call.

But I can think of three potential avenues, albeit very remote, for finding an overflow when trying to gain access via an inbound fax modem.

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:

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.
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 crappy data imaginable, 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 kind of problem.

TSI STRING

During the initial setup of the call, both stations swap ID strings:

CSI - Called Subscriber Identification
TSI - Transmitting Subscriber Identification

The answering machine announces its CSI string to the caller, and the caller responds with its TSI string, and they are typically phone numbers. The fax specification (CCITT T.30 5.3.6.2.4) limits these strings to 20 characters from the set "digits, space, and +". But in practice, almost all fax systems allow full ASCII.

Most commonly, server software just sticks the received ID string 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.

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, and certainly using a class 1 modem. This doesn't sound too promising, but it's not an area that would really get tested on the server side.

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" (CCITT T.30 5.3.6.1.1) , 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 from just one vendor.

Unknown NSF frames are supposed to be ignored, and I think that most computer-based fax software doesn't use them at all. 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 not researched this since my professional focus turned more toward security.

Navigate: More Tech Tips