Searching For Backdoors From Rogue IT Staff
WHiTe VaMPiRe writes "When IT staff are terminated under duress, there is often justification for a complete infrastructure audit to reduce future risk to a company. Here is an exploration of the steps necessary to maintain security." Of course the first piece of advice is to basically assume you've been rooted. Ouch.
I usually put in multiple backdoors. Not out of malicious intent but because I support customers who are so far away that I don't want to drive out there all the time. Now this might include software or even out of band management, VPN, etc. Basically, if you put yourself in a position where you have to fire your IT staff then you are a moron. Always do background checks because you are going to be giving these people the keys to the city.
If you're seriously considering this as a possibility, I'd say treat it like a DR drill. Burn everything down to bare metal and restore only the data. It's the only way to be sure...
That seems a bit risky. I cannot see any manager worth his salt giving authorization to purposely destroying data "to see if the backup works".
That's because the order of operations is out of whack.
Rebuild, then cut over. Same result, less risk.
Sorry for glossing that over.
It's fairly impossible to audit all systems to the extent needed. You can easily burn enormous amounts of money and time doing that, and the remedies can disrupt production more than the damage the disgruntled employee would do.
There are so many ways to hide what you're doing that even rebuilding all systems isn't enough. Dangers can hide not only in backdoors, but dead man switches built in to compilers, stored procedures in databases, backups, or the Boss' PC, for that matter.
So instead of sending good money after bad, it can be immensely sensible to let things be and instead try to ensure that the employees don't leave disgruntled.
The worst timed logic bomb I have had to deal with was by an intern who was looking for more pay. He had written a statistical analysis program that would have started to introduce subtle errors several weeks after he had left. If I had not found it then our stats would have become useless after a few months of that mangling. I assume he was hoping we would notice data errors, panic and re-hire him to fix it without realizing that he had caused the errors. I became suspicious when the timestamp on the Java source was newer than the class file so I did some reverse engineering. He had edited the logic bomb out of the source after compiling.
I had to administer a system when the vendor's software would fail on the rollover for the day. So it would fail at 5 am, and I would have to be the one to come in to fix it. As it happens at least once every two weeks I started to SSH in to fix it rather than rush to work and have to work an extra three hours that day (and not be compensated for it). The policy that I fought to implement at work was to do a quick audit, change any passwords/keys for any remote entry and to actually create passwords for many of the accounts that did not have passwords. So done and done I thought.
To continue: I had many problems with upper management, one of which was their wanting me to 'tweak' time sheet accounting so that new entry level minimum wage employees were paid for as little as 75% of their legitimate hours worked. I thought this was particularly dickish as they fired employees on a project basis and anyone was usually fired within two weeks. So I quit and tried to get myself as good as a parachute as I could.
Well two weeks after I left I found out the newbie replacement didn't perform the audit when I accidentally clicked on a bookmark at home (Putty) and I was suddenly in a server from my old job. I logged out and didn't feel particularly compelled to tell them that my keys were still trusted. About a month later I made the same mistake. The hole was no longer there. I thought to myself, "Good for him. I guess he's not so incompetent at all."
But curiousity a la Facebook and Twitter revealed that a server had actually gone down that day. Apparently there was a 'rm -rf' oopsy!!!
The story continues, but the end result is that he managed to destroy three servers within a month of my leaving. If I had been malicious I don't think I could have caused that much destruction...
for those that are terminated and have no intention of connecting back in ? After all, if I am let go, the last thing I want is for my old credentials to be used by someone to trash something and have suspicion fall on me.
Nullius in verba
Relatively current events counterexample A: Terry Childs
He may have bucked the chain of command, but if his employer had sat him down, said, "look, Terry, we think you'd be better off somewhere else - we're going to keep you on until you find a better opportunity, and we're going to help you do that," he would have probably said, "yeah, but you have nobody else here who can handle this thing. You're going to need to hire a firm to manage this or get some better talent on staff," which seemed to be his motivating concern. And so they probably would have done that, and nobody would have gone to jail.
Instead it seemed like a "give us the passwords and um, no you don't need to clean out your desk, why?" kind of scenario. I'm not meaning to absolve Childs of incorrect behavior, but a little Golden Rule would have gone a long way there. I think this is what the GP meant by not disgruntling the employees.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
If the back door is as well hidden as the one Ken Thompson hid in an early version of Unix, a complete audit of the source code and complete recompile of everything won't be enough to get rid of it. Of course, not many people are capable of pulling that kind of stunt off.
Good, inexpensive web hosting
Most business owners/managers have a better relationship with their mechanic than with their IT people. And why not, the Mercedes (insert any other prestige vehicle here if desired) parked in the MD's parking spot is considered a far more valuable asset to the business than IT. At least that's my exerience.