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 --------------------------------------------------------------------------- ----------------------------------------------------------------------------
Current thread:
- potential fax server security issues? Maarten (Jan 13)
- Re: potential fax server security issues? Steve Friedl (Jan 13)
- RE: potential fax server security issues? Travis Potter (Jan 13)