The ABAP Detective Never Signals an Interrupt

Part 1

I was playing a game of Ping with my local host, when in to my $home walked the most unlikely looking customer prospect I’d seen in an epoch. He was wearing a Unicode, in a shade I’d never seen this side of the Getty terminal. What was most noticeable was his fedora; I’d never spied one that flavor on an enterprise security hack.  Clearly, he was from the underworld of the process table. When he spoke, it wasn’t the clear text I was expecting, but a mixture of DES and DOS that belied his Jersey origins. Made me think of dialing a long-forgotten telephone exchange operative… what was the number? MUrrayhill something? I know it rings a bell.

I invited him to sit down, and have one of the fine doughnut cores I picked up on the last system crash. He began to weave a tale of lost parcels, dead-end aliases, fallen post offices, mimes, and some kind of relay mismatch that was jamming his transmissions. After getting some Java into him, I began to sort out his tale of stream editing into regular expressions. From what I could make out, there was a consortium of enterprise racket boys, I mean architects, that were enforcing a yet another push of central directory operator replacements. I did not grep if he was alleging mail fraud, or if this was more a swap of the old post office location for a new address on the edge of town. Virtually, it could be anywhere. I began to wonder “who am I?” to take on this case statement.

Figuring there was no exit, I told him I’d look into his missing package, finding the code source if I could, for $IO per day, plus acct expenses. I’d dev into the matter. He left me with a simple shell of instructions:

• Find where the mail relay host was corrupt.
• Make sure replies were addressable
• Loop until done

With that, I headed uptown to the address blocks way over my simple 32-bit region. On the way, I stopped off at the local admin parlor to pick up the rap sheet of one “Scot“, a known stool (I mean carrier) pigeon and checked where he might be homing. From there, it was a quick traceroute to the headquarters of Universal Imports, where I knew I could find answers to the page faults I was given. Slipping my contact a pile of data, I was ushered into the ring of colonels. At first, they’d only let me peer at clues I wanted to see from client side windows into the sandbox, but at least I began to parse what was being dumped.

The “system status” display looked like this:

Nothing substantial here, even with the redacted phrases, yet the bright green message of “SMTP” was clear enough. It had been years since I had had any trouble sending mail, but say “sendmail” around the most hardened ABAP code hackers, and you’ll likely see a patina of green nearly shade.  Not much else to be compiled from those sources, so I had them open the books for a closer gander.

This was more interesting, I thought, a few blotted out network destinations, but the fact was someone had been at work wiring up incoming and outgoing messages before I got there.  With a few more well-placed two-bits of the realm, I was shown the innermost workings of this net; the Mail Host and the Mail Port settings were all I needed to see that the node was a set up. I now had something to compare and see if this was uniq.

One important fact I could cut from the info they shared was the freshness of the tracks.  Though almost a year had passed since this file was touched, that was pretty recent by my standards.  When they let me look at the main office, a diff picture began to grow.  Of course, this hub was busier than the dusty sandbox I was shown first, and despite few visible errors, they weren’t /dev/null/.

Since I had already seen the other settings, I could tell I had a solid lead.  These tracks were nearly a decade old, had the quaint upper case lettering of an AOL veteran, or even a Cro Magnon Compuserve relic, and told me these sockets are blocked. Or will be, before long.

The other incompatibility I noted was the lack of specific addresses. It was like this was the main post office, with a general delivery box for anybody, which isn’t too good for biff, if you know what I mean.  But the clues are what the clues are, and it was time to do more digging.

After scoping out the message passageways, I needed to regroup and validate my parameters.  If what I thought were true, the old post office was headed for rm boulevard, no mv allowed.  Any characters trying to forward mail through that address were going to be defunct, or worse, zombies.  To get on track, I headed to the tmp agency that knows where every operand has worked, and where there are openings in anyone’s pid.  I checked in the hotel lobby downstairs, to C if there were any claim checks in the lint.  Why? bc.

For a promise of a future init, I was given a peek at the groups list for mailing.  In this instance, the wheel belongs to batch workers, also known as daemons or background tasks. These aren’t the same kind of background those SAP types might be familiar with, but close enough for the grand jury.  Only a few of these mugs had return addresses, yet something told me that was going to cause the worst kind of interrupts.  The silent kind, the ones that don’t leave a mark but leave you wondering where in the code are you.

I looked at a few more specimens, of the SU01 [Table for Username & Email address] variety, finding a lot of blank cartridges in my $path. Some of these records were so incomplete, it gave me that feeling someone was walking across a bit bucket.

Just to be sure I was on the right code page, I thumbed over to my own address pointer. Sure enough, that mainly looked familiar, and a lot more padded with non-blanks than the waldos running the night shift. Email address looked good, but testing it, with my lack of inner circle connections, was going to mean a long uptime.

Part 2

Flagging down a cab, I headed to the seamy side of town, where I context switched from glossy interface palettes to the staccato beat and gritty vt220ness of command line city. The first thing I was looking for was backups in the tunnels underground, which would show more of when things went awry, not Y.  I didn’t have a PKE meter; the best I could do was chdir to the spool spot, and list the inodes.  I started with the sandbox, to level my gauges, and found one stale user, identifiable by having a booking shot ID number instead of a nameplate, one small stale admin (or “adm” in street parlance) folder, and a mother lode of messages intended for the big cheese, the root of all devices. Or, as Knuth would have it, “Premature optimization is the root of all evil (or at least most of it) in programming.”

Before I drilled into deeper subdirectory levels, I needed to leave messages for my cohorts, so if I didn’t make it back to the surface, they’d know which filesystem to find me on.

Completing that round of interrogations, I had another cup of Java, and went back to work.  The most likely place for postmarks to be found was in the syslog neighborhood, a complex blend of accountants, toughs, and people who seem to have more to talk about than to say.  There’s a lot of data here; best not to let minors view this without accompaniment.  A little trick I learned in juvenile hall was “grep -i mail syslog.log” to return those records I needed, and not those I didn’t.  Very few messages visible in the evidence here, but since it’s the research box, not too surprising.

Moving on up to the main street, I spotted much more volume of bulk mail, yet essentially the same patter of adm, ex-user, and big wheel records.  Good to know there were only a few suspects to tail, and if I could get the key to the kmem group, I was in like Flint.

Same search routine as above, with many more results, forcing me to add a filter to throw away “I_9” messages to be able to spot the address and return address data fields on enough messages to tell me who was going to get a subpoena for more questions.

Part 3

If I ended up in a cor(ner) dump, it would have been my own sigaction  Searched the obvious places for the sting; had to be a wire caper. It was time to toss out the graphics and get all 24 by 80 on this problem. I knew there were at jobs, cron jobs, and even enterprise scheduler bag jobs, I mean batch jobs.

My first clue in this area of the investigation was a short but complex command.  I’ve altered it for general audiences.

We’ll ignore the “-r” flag, as it’s not quite in the documents, and I’m unsure who put that in. It could be “someone” or “somewhere” depending on what R means.  The “-s” string is simple enough… the subject of the message; the recipient is actually a list, and the body of the text is supposed to be a readable file 3 levels down. Forget about error checking. If this command succeeds, great, if anything goes wrong, it will be hard to tell where.

This message command, and the one that follows, are just bit players.  The switch, or sting, is going to be at another level entirely.

Better, since the path is complete, but a few pieces are missing.  There’s a security hole, even inside the main security hole. [ http://www.securityfocus.com/archive/1/461958 ].

Nearing the end of the trail, I looked where the mail relay is configured.  In some systems, it’s in /etc/mail

In other systems, it might be in /etc/sendmail, or /etc/postfix, or well, anywhere.

I dragged my exit function back to the subway, since I’d spent most of my $expense on termcap functions.  It was going to be a long night, poring over the crash dumps and var logs, trying to identify all the perps that had set up mail rackets, fraudulent or not, to see which ones were going to survive the tightened surveillance rules.

When I got back to my apartment, there was a message from the answering service, saying mail from the SCN syndicate was being blocked somewhere.  Would I be available to take the case?  Not likely I said, unless serious simoleons were involved.