Slashdot Mirror
When Sysadmins Go Bad
An anonymous reader writes "Here is a story about what can happen when you think you're being oh so clever. This sysadmin planted so-called logic bombs on the systems he was responsible for and then quit. He also tried to game the stock market, buying put options on his former company, hoping to cash in when the disaster he engineered struck. Who can companies trust if they're afraid that this kind of thing can happen? How can they prevent it?"
Something similar happened to my Dad's business about 15 years ago. Back then, they just trusted the employees. For some reason I can't recall, they decided to fire the sysadmin that was running their billing systems and gave him a months notice. During that month, they let him take time off from work to interview at other places and were generally pretty nice about the whole thing.
A couple weeks after he left, the system started crashing and losing data. Apparently he used a rather well-known bomb because the company they used for support was able to dial in and found it rather quickly. He was charged, arrested, tried, and found guilty. It was a big deal because the state (South Carolina) had just passed some really though computer crime laws at the time, and the Attorney General wanted a "test case" for the law.
My Dad and his partner's requested that the guy not get any jail time since he had a wife and some kids, but he got major probation and a huge fine (something like $60,000, which was a lot back then). Plus he now has a felony charge on his record. Last I heard, he had gotten out of the computer biz and was working in a family business.
Anyway, the short lesson is: if you're a company firing someone with privileges, pay them the two weeks or whatever but don't let them back on site. And if you're the guy getting sacked, don't try to get revenge through sabotage; it's just not worth it.
As an aside: every place I've worked had a policy that whenever someone was fired they were led to their desk with a cardboard box, then escorted out of the building that very moment.
... pull a stupid crime and spend the rest of your life in a state-funded institution.
Gets my vote. I saw this blow up at my current workplace when a former IT drone's account was deleted (not suspended) as soon as she left the building, without anyone realising it was used as the service account for many things, including the backup server. It took many hours to track down all the things it was used for and to furnish them with saner accounts. I think this probably counts as an accidental logic bomb.
The really sad part of this is tale that it took over a fortnight for anyone to notice in the first place. Weep.
(I'm not part of the local IT department, so I'm blameless with respect to this particular fuck-up. I commit enough fuck-ups of my own without claiming responsibility for anyone else's!)
"Are you being weird, or sarcastic?" said Emma. I said I didn't know because I get the two feelings mixed up.
Here in Venezuela, when the Oil strike begun some sysadmins blocked and placed logic bombs in the critical computers. It is costing the country an average of US$ 15 million a day. The computers that control the fuel-load process in the tankers where so sabotaged that any try to get the system up would end up spilling fuel on every "island" (the place where the fuel truck loads). The only way to stop the spill would be to activate the emergency system in the plant. Gladly (it's already very known worldwide) the goverment set up a "hackers team" to take over all the sabotaged industry computers. Most of them are running Solaris or Windows NT 4, so it wasn't too hard to break all the systems. If you calculate: US$ 15 Millions * 16 days = 240 Million US$ ... and most of it is because the admins who sabotaged the critical computers.
You must be inexperienced. I've set up systems where no one had root access. You set up sudo (or one of its commercial clones) to give specific people permission to do specific things, then you write a script to change the root password to a very random string and send it to a real printer. As soon as the printer delivers the goods (in the presence of one of more officers), it is folded and placed in an envelope (which everyone signs on the seal) and locked away. Any emergency big enough to require the password needs to be brought to the possessing officer's attention anyway, and anyone can look at the envelope to make sure that it hasn't been tampered with.
Nothing for 6-digit uids?
He can't. I've had this happen to me one or two times. I've been pushed in to sysadmining (dammit, Jim, I'm a programmer, not a sysadm!) in this small association (about 60 employees, about 60000 members), and initially just assumed the system I took over was OK. After a year or so I discover, quite by accident, the first horrible thing... Every user PC has a small script on it, that contains the root password to the main server in plaintext.
Apparently, no-one knew. I was responsible, even if it was my predecessor (or his) that had written that script. What to do? Go up to the boss and say "Hey Joe! Funny thing, any employee may have had root access to the DB in the last five years! Ain't that funny?". No. Fix it. Shut up.
There were a few almost as horrible things I fixed quietly over the next few months.
I also have to confess that I have did a horrible blunder myself, that has gone undetected. What do you do when you find that a bug in an old program you wrote has lead (over the last six months) to >4% of your members mailing addresses beeing slowly mangled? When membership dues are mostly collected by mail? Which has lead to large losses for the association, and great unhappiness among the members?
Fix the bug, correct the adresses as much as possible, delete the evidence, lie when confronted. That's what you do.