Forgot your password?
typodupeerror
Security IT

Searching For Backdoors From Rogue IT Staff 328

Posted by CmdrTaco
from the i-left-you-a-present dept.
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.
This discussion has been archived. No new comments can be posted.

Searching For Backdoors From Rogue IT Staff

Comments Filter:
  • Seems like it would make sense to simply terminate "with extreme prejudice" when getting rid of potential security threats....
    • Three words (Score:5, Insightful)

      by pjt33 (739471) on Tuesday August 24, 2010 @05:47PM (#33362220)

      Dead man's switch.

      • Re: (Score:2, Funny)

        by frinkacheese (790787)

        It's great for a bit of extra consultancy work when you have been made redundant too.. Walk out and guess what, a week later things break and you're on $1000 a day fixing it ;-)

        But really, the best thing to do is to treat your IT staff properly in the first place.

        • Re: (Score:3, Interesting)

          by Ironhandx (1762146)

          This.

          I've worked in a highly stressful environment before where I didn't know if I was going to still have a job the next day or not. I had everything set up sufficiently complex but still for good reasons, that if they had fired me getting someone else to fix it would have been a nightmare and cost them a fortune, which they would find out as soon as they tried to get someone else to go in and fix it.

          Since I left on good terms I overhauled everything before I left and took out most of the non bog standard

          • Re:Three words (Score:5, Insightful)

            by Anonymous Coward on Tuesday August 24, 2010 @07:20PM (#33363330)

            This.

            I've worked in a highly stressful environment before where I didn't know if I was going to still have a job the next day or not. I had everything set up sufficiently complex but still for good reasons, that if they had fired me getting someone else to fix it would have been a nightmare and cost them a fortune, which they would find out as soon as they tried to get someone else to go in and fix it.

            Since I left on good terms I overhauled everything before I left and took out most of the non bog standard bits I had implemented. They ended up with a slightly worse but fixable in a pinch system.

            Had the work environment been less stressful I wouldn't have felt it necessary to go through all of the trouble, but they decided to make it that way, so I decided to build some security into my job that was otherwise nonexistant.

            This is still an extremely unprofessional thing to do. What if it breaks while you are on vacation? What if something happens to you? What if you get mono and can't work for three months? What if you get in a car accident and are in the hospital for months? What if your code gets audited and you get called out for writing shit code?

            • Re:Three words (Score:5, Insightful)

              by PitaBred (632671) <slashdot.pitabred@dyndns@org> on Tuesday August 24, 2010 @08:20PM (#33363912) Homepage

              If they cared about that shit happening to him, they would have treated him better. What goes around, comes around. They aren't treating him well enough to care.

              • Re: (Score:3, Insightful)

                by Krneki (1192201)
                Exactly, if you don't give a shit about your employers, don't expect any love in return.
            • Re: (Score:3, Informative)

              by dbIII (701233)
              What about actually applying some reading comprehension skills to the portion quoted? Take note that things were not deliberately complicated but ended up that way to solve problems.
              Arcane performance tweaks by people that know the stetup backwards are quick while well documented proceedures designed for newbies take time to develop. You can aim to get there in the end, but the above post appears to be about what would have happened if things were stopped part way through.
            • Re: (Score:3, Insightful)

              by ultranova (717540)

              This is still an extremely unprofessional thing to do.

              Professionalism goes both ways. If you keep your employees guessing whether they'll still have a job tomorrow, they'll keep you guessing whether you still have a system tomorrow. Why would you expect to get more than you give?

          • Re:Three words (Score:5, Informative)

            by Cramer (69040) on Tuesday August 24, 2010 @07:54PM (#33363658) Homepage

            I'm sorry, but that's the a**hole way of running a network... make the place unnecessarily complex so you're the only one who knows how any of it works so "they don't dare fire me." That rarely works out well -- and often encourages firings. Having been the replacement and consultant called in to sort it all out, I support the death penalty for such people.

            • Re:Three words (Score:5, Insightful)

              by Evil Shabazz (937088) on Tuesday August 24, 2010 @09:33PM (#33364434)
              Indeed. In my experience, the folks who talk about making systems "so complex only they know how to fix them" don't actually really know what they're doing anyway. The real truth is usually that they've got things set up so batshit crazy trying to hide their mediocrity in this "you can't fire me now!" excuse.
              • Re:Three words (Score:4, Insightful)

                by lrichardson (220639) on Tuesday August 24, 2010 @10:56PM (#33364998) Homepage
                Yes and no. I've done so flashing-star, how-the-heck-did-you-get-that programming, mostly because of a unique position that straddled various corporate silos.

                Two killers, i.e. 'making them so complex only ...'

                1/ Not having the time to clean stuff up. If it works, management generally wants you to move on to the next fire.

                2/ Documentation oversights and assumptions. "Check the syslog for errors" doesn't cover what to do when errors arise. I'd reached the point of coding the automated sending of e-mails on errors - with the fix included - to the person running a job, on dozens of issues. Things that one just assumes after years of experience are complete show-stoppers to someone who doesn't have that same experience. And it only shows up when someone else does try and run something, per the documentation.

                &, of course, 1.5, not having the time to do any documentation ...

                I like automating the heck out of stuff, handing it off to some poor schlub to run as needed/scheduled, and moving on to the next problem. But I also recognize that it's done me out of a job a couple of times. Which really, truly sucks.

                The best advice I received from a friend was "Don't make yourself indispensible. You won't get vacations."

                It's a trade-off. I think I prefer being viewed as a valuable asset, getting new challenges, rather than the only guy who knows how to fix something.

                • Re:Three words (Score:5, Insightful)

                  by Antique Geekmeister (740220) on Wednesday August 25, 2010 @12:18AM (#33365434)

                  You've left out number 3:

                  Being completely forbidden by your manager, or the client, from doing it the faster, cheaper, and simpler way in favor of some approach they're more familiar with, and having to work around the crazy in-house architecture they've already deployed and lack willingness or political capital to throw out.

          • Re: (Score:3, Informative)

            by Mr. Freeman (933986)
            Everywhere I've been inserting complexity to ensure job security is the number one (or at least in the top 5) way to find yourself without a job. Making something intentionally complex to the point that only you can fix it is unprofessional and, at least in the case of engineers, unethical. The only reason these firings are done without cause as opposed to for cause is because it's more paperwork if you're actually fired for being unprofessional.
            • Re: (Score:3, Insightful)

              by TheRaven64 (641858)
              Even if it keeps you in a job, it also has the effect of keeping you in the same job that you're currently doing. When management is looking for someone to promote, they're not going to promote the person who is indispensable in his current job...
          • Re: (Score:3, Insightful)

            by kiwimate (458274)

            Wow...

            I've worked in a highly stressful environment before where I didn't know if I was going to still have a job the next day or not.

            Life is too short to put up with that amount of stress. You should've been job hunting.

            I had everything set up sufficiently complex but still for good reasons, that if they had fired me getting someone else to fix it would have been a nightmare and cost them a fortune, which they would find out as soon as they tried to get someone else to go in and fix it.

            Wow, again. So the client is really screwed if you end up in hospital with pneumonia for two weeks (I pick that example because it happened unexpectedly with one of our developers within the past 12 months). A professional sets things up so they are easy to maintain and trusts in his ability and skill to get jobs, based partly on that.

            Since I left on good terms I overhauled everything before I left and took out most of the non bog standard bits I had implemented. They ended up with a slightly worse but fixable in a pinch system.

            So out of the generosity of your heart, and because you left on good terms, you de

        • Re:Three words (Score:5, Insightful)

          by CharlyFoxtrot (1607527) on Tuesday August 24, 2010 @06:03PM (#33362448)

          But really, the best thing to do is to treat your IT staff properly in the first place.

          This. I don't understand why it's so hard to grasp for some organizations. Pissing off IT is like telling your mechanic he's an asshole while he's working on your brakes. Sure most are consummate professionals but sooner or later you'll hit on one that isn't and then there'll be hell to pay.

          • by blair1q (305137)

            But really, the best thing to do is to treat your IT staff properly in the first place.

            This. I don't understand why it's so hard to grasp for some organizations.

            Organizations learn slowly, and often by having their cost-saving measures (aka laziness) blow up in their face, then they overcompensate and kill efficiency.

            The correct answer is "trust but verify,", aka "internal controls." You don't let one of your accountants sign your checks, so don't let your admins do anything without cognizance and review from another admin. Then it takes two people conspiring to screw you over, and if they both know it's better for them to catch the other screwing you over, you w

          • Re: (Score:3, Insightful)

            by drsmithy (35869)

            I don't understand why it's so hard to grasp for some organizations.

            Because even after multiple demonstrations otherwise, upper and executive management cling tightly to the fantasy that experienced mid-level+ IT (and other) staff are generic and can be disposed of and replaced at will, with essentially no loss to productivity.

          • Re: (Score:3, Interesting)

            by jasonwalls (1492425)
            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.
      • Two words (Score:2, Insightful)

        by Sycraft-fu (314770)

        Prison sentence.

        Seriously trying to do something like install a dead man switch to fuck over your employer would be the height of stupidity. Wonderful way to end up with a sentence that make the Child's thing look lenient. While I realize that pedantic geeks think they could cover their tracks that isn't the case. They don't have to prove it was you beyond any and all doubt, they just have to prove it was you beyond a reasonable doubt. If they can show means, motive, and opportunity, they've gone a long way

        • I would recommend subjecting all IT staff to a psychological evaluation test. Myself included. Who wants to work with egotistical assholes? I sure don't. I love working in a non-abusive collaborative team environment.

          • by blair1q (305137)

            But that's where we put the egotistical assholes to keep them out of the rest of the building...

        • Re: (Score:3, Insightful)

          by Peach Rings (1782482)

          You could easily just badly document or fail to document passwords and configuration info and stuff. As long as you're around and working with the systems daily, everything runs smoothly. If you get fired, there's confusion with the new guy and your memory fades... it's not like they can really tell exactly what isn't a matter of the new guy not being up to speed for weeks. And you're not responsible for giving them consulting services for free after they fire you. If they can't figure out the non-standard

          • Re:Two words (Score:4, Informative)

            by fluffy99 (870997) on Tuesday August 24, 2010 @08:15PM (#33363858)

            You could easily just badly document or fail to document passwords and configuration info and stuff. As long as you're around and working with the systems daily, everything runs smoothly. If you get fired, there's confusion with the new guy and your memory fades... it's not like they can really tell exactly what isn't a matter of the new guy not being up to speed for weeks. And you're not responsible for giving them consulting services for free after they fire you. If they can't figure out the non-standard port numbers you used, then that's their problem.

            Childs took an idiotic stand where he admitted he knew the passwords and refused to hand them over. That's not the most lenient case, that's the worst case I can think of other than destroying data.

            Even worse, he deliberately setup the routers so he'd have to manually reconfigure them if/when they rebooted - in other words a deadmans switch.

        • by timeOday (582209)
          Sure, it would be dumb to do. But it does happen, thus it is a legitimate security concern.

          As for preventing problems by firing anybody who's going to do something wrong before they do it, good luck. Even Stalin wasn't 100%, and not for lack of trying.

        • Re: (Score:3, Insightful)

          by Requiem18th (742389)

          Did you hear *woosh* over your head? That's the sound of missing that he was proposing revenge for being terminated with extreme prejudice. If you are dead, you don't have to worry about being jailed.

          If they fire you without firing AT you, that's good reason to kindly warn them to remove the DMS.
          All of this of course, as a joke.

        • Re: (Score:3, Insightful)

          by X0563511 (793323)

          You know what a dead-man's switch is, right? The joke he was replying to was that it was better to kill the employee than to fire.

          The response was to build a dead-man's switch.

          Hard to go to prison after a 9mm to the brainstem...

    • by arth1 (260657) on Tuesday August 24, 2010 @05:54PM (#33362308) Homepage Journal

      Yeah, that will really solve the problem of time bombs and dead man's switches...

      How about not disgruntling the employee in the first place?

      • How about not disgruntling the employee in the first place?

        It's a good policy and should be encouraged, because it does solve most problems. However, believing that will solve all your problems rests on the assumption that your employees are basically rational and won't do anything crazy just because. This won't always be true.

        Relatively current events counterexample A: Terry Childs.

        • by duguk (589689)

          How about not disgruntling the employee in the first place?

          Relatively current events counterexample A: Terry Childs.

          I would argue that Terry Childs was disgruntled, being as he had an ongoing disciplinary case.

          • by Surt (22457)

            So the solution, clearly, is never to hire anyone who in the future might cause you to have to resort to disciplinary action.

        • by bill_mcgonigle (4333) * on Tuesday August 24, 2010 @06:40PM (#33362868) Homepage Journal

          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.

      • Seriously, it takes a rather large amount of egomania and lack of respect for others to consider doing something like that. Most non-sociopathic types just wouldn't do it. They wouldn't rig up something to damage their employer just on the off chance they ever got mad. Anyone who seems to be that kind of person, well show them the door before they have the ability to cause trouble.

        While I fully agree employers should be nice to their employees treating it like a hostage situation where you can never do anyt

      • grow up (Score:4, Insightful)

        by luis_a_espinal (1810296) on Tuesday August 24, 2010 @07:55PM (#33363674) Homepage

        Yeah, that will really solve the problem of time bombs and dead man's switches...

        How about not disgruntling the employee in the first place?

        Oh, grow the hell up and welcome the nature of life.

        Though there are work places that indeed are festering, pedantic shit holes, my experience has been that people who are disgruntled enough to commit a stupidity don't necessarily work in a place causing them to be so disgruntled in the first place. They are simply stupid assholes who either have a sense of victim-hood or are too arrogant and socially incompetent so as to pop a vein at the slightest work-related discomfort.

        Work is work, it's not supposed to be pleasant all the time. We get paid to do work that has a certain level of difficulty, both technological and sociological. It has always been so, it will always be so. Half of the time the fault of being disgruntled is in you. How you handle that shit is ultimately one's responsibility.

        If you are a mature person with a sense of, oh I dunno, fucking professionalism, you will never get *that* disgruntled no matter the working conditions. If you are not a mature professional and you cannot tell professionalism from shit flinging monkey riding a banana-shaped tricycle, then you'll inevitably construe any slightest difficulty into an affront, building each one of this up, turning you into an arrogant, festering boil of disgruntled human suckage and social incompetence.

        And for those who truly voted that post as insightful, man, grow up, really.

        • by Viol8 (599362) on Wednesday August 25, 2010 @07:14AM (#33367096)

          "f you are a mature person with a sense of, oh I dunno, fucking professionalism, you will never get *that* disgruntled no matter the working conditions."

          Oh please, and you're telling OTHER people to grow up? Sounds to me like you've hardly had any work experience in the real world. It doesn't matter how professional you are - everyone has certain buttons that can be pushed and in a long working career believe me , someone WILL push them eventually.

          Also you might disguise your young age a bit better if you didn't swear every paragraph.

    • I know what you're thinking, but not every company has a nuke stationed in orbit. Let's try to be practical here.

    • Re: (Score:2, Interesting)

      by cjb658 (1235986)

      Reminds me of a speech Ian Angell gave at Defcon. I guess a CEO of a bank there terminated and outsourced the entire IT department. A couple days later, it surfaced that he had all kinds of pr0n on his computer.

  • by Nick (109) on Tuesday August 24, 2010 @05:46PM (#33362202) Journal
    to audit your system under the assumption you've been rooted should happen once a year at a minimum anyway, not just when you suspect a rogue employee left on bad terms. I've worked at places that never changed passwords and I found former employee logins enabled from months ago..
    • by arth1 (260657) on Tuesday August 24, 2010 @06:02PM (#33362444) Homepage Journal

      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.

      • by techno-vampire (666512) on Tuesday August 24, 2010 @06:50PM (#33362956) Homepage
        It's fairly impossible to audit all systems to the extent needed.

        If the back door is as well hidden as the one Ken Thompson [foldoc.org] 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.

    • Re: (Score:3, Insightful)

      by bloodhawk (813939)
      That would be nice but is in reality completely impractical. The time and money to do such an audit properly would be more expensive than just rebuilding your entire environment from the ground up. I could effectively hide a rooted box or backdoor on windows or *nix systems I look after that unless you are going to strip the boxes and mount the drives on seperate boxes to check the binaries you are simply not going to find the holes.

      The ONLY way to handle a suspected rooting is a rebuild, anything less i
  • by BobMcD (601576) on Tuesday August 24, 2010 @05:49PM (#33362238)

    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...

    However, before taking my advice, I'd suggest you get your boss to sign off on it, whichever way. Present a list of options from 'ignore it' to 'burn everything' and have them pick. This way, whatever happens, you're covered.

    • by Locke2005 (849178) on Tuesday August 24, 2010 @05:51PM (#33362276)
      "I say we take off and nuke the entire site from orbit. It's the only way to be sure."
    • by Meshach (578918)

      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".

      • by BobMcD (601576) on Tuesday August 24, 2010 @05:57PM (#33362366)

        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.

      • You don't start with 'burn the building down'. You start with restoring to a backup set of hardware and doing basic validation, then work up to milton style DR by steps. Besides, backups are never the problem - it's the restores.
      • Re: (Score:2, Informative)

        by fishbowl (7759)

        >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".

        We do it routinely, but it's not chaotic or risky like your choice of words makes it sound. OTOH we have invested a lot of money and brainpower into getting the redundant system we need to have in order to fail over a production system, tear one down, build it up again, verify it and put it back into production. That costs money... and probably not something

    • 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...

      To elaborate on this idea I would emphasize that the existing and working hardware is not touched, ideally at least. Use a new/different system (your backup/spare hardware - which should be tested anyway and isn't this a good test?) or maybe a new virtual machine. Once the OS and apps are restored from trusted sources, the data is restored, and its verified that all is well then replace the original hardware. Maybe the original hardware now becomes the back/spare for the next machine to go through this p

    • Backups are easy, restores are not.

      1. How do you know everything was backed up properly to begin with? Are you sure those logs are being interpreted correctly?

      2. Almost every small to medium size businesses do NOT perform disaster recovery drills. Running a test restore of small data is one thing, but a full scale DR drill is quite another task entirely. If they do, it's because they have extra hardware to test them on and/or can spool up a VM. Again, were not talking about fortune 500 companies here with a

      • by BobMcD (601576)

        You're not suggesting any alternative that I can see. I'll just assume you're advocating the 'head in sand' approach, and assert that the new IT guy cannot afford that risk either. The boss makes the call, or you walk. Better to be job hunting than to be sacrificed when the ousted guy attacks the network, in my opinion.

        To answer your concerns, however:

        1) It needs testing, period. Further I'm absolutely not advocating recovering everything. Data only. Reinstall the apps and platform by hand.

        2) They do

    • by Lehk228 (705449)
      and the data being restored contains a buffer overflow exploit that reroots the new system
    • 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...

      However, before taking my advice, I'd suggest you get your boss to sign off on it, whichever way. Present a list of options from 'ignore it' to 'burn everything' and have them pick. This way, whatever happens, you're covered.

      That takes care of backdoors in the OS assuming you run everything stock. But if you're running custom in-house software that might have backdoors too so it'll still need to be audited. I wouldn't recommend this approach except for the most extreme cases anyway. Best is just to keep a log of all installs and changes from stock and have outside auditors come in regularly to check for anything that can't be accounted for as well as audits of all installations. Not to mention having a strictly enforced change

  • little OT.... (Score:3, Insightful)

    by Anonymous Coward on Tuesday August 24, 2010 @05:50PM (#33362260)

    One of many reasons CEOs are given golden parachutes are to keep them quiet about trade secrets and certain contacts. Whether or not that happens is debatable, but discretion is basically paid for.

    Why not give similar parachutes to IT admins to follow these unwritten practices? If the CEOs are the frontmens, ITs are the infrastructure of the organization. Treat them like gatekeepers instead of disposable footmen. They have the keys to the castle. And all the secret entrances.

    • One of many reasons CEOs are given golden parachutes are to keep them quiet about trade secrets and certain contacts. Whether or not that happens is debatable, but discretion is basically paid for.

      Why not give similar parachutes to IT admins to follow these unwritten practices?

      Since golden parachutes have been a source of abuse and unintended consequences maybe the concept should not be more widely used?

      FWIW golden parachutes are not really about keeping quiet regarding trade secrets, contracts and other material non-public information. Contracts, non-disclosure agreements and other legal tools already cover this area.

      • by dbitter1 (411864)

        Golden parachutes can be effective if reasonably written.

        For example, cutting all the legalese out of mine it waters down to "your non-compete is as long as your severance package of normal salary". Thus, they give me a year's pay of severance, I don't show up at my competitors door for a year. If the checks bounce, I'm there, and the NDAs say I can do it free and clear.

        Having pissed off sysadmins because your employer is an ass is one thing, and I agree there is no reason to torment the keepers of the keys

    • Re:little OT.... (Score:5, Insightful)

      by CharlyFoxtrot (1607527) on Tuesday August 24, 2010 @06:21PM (#33362616)

      One of many reasons CEOs are given golden parachutes are to keep them quiet about trade secrets and certain contacts. Whether or not that happens is debatable, but discretion is basically paid for.

      Why not give similar parachutes to IT admins to follow these unwritten practices? If the CEOs are the frontmens, ITs are the infrastructure of the organization. Treat them like gatekeepers instead of disposable footmen. They have the keys to the castle. And all the secret entrances.

      The janitor has all the keys to the building and the cook could poison everyone if he wanted but those people aren't afforded the respect they deserve either. CEO's are given golden parachutes by their buddies who they'll see at the golf club and who they can maybe return the favor later on the board of some other company. We're just staff and staff don't get golden parachutes, they get concrete shoes.

    • by b4upoo (166390)

      Giving benefits to people according to the potential harm that they could do is not right according to me. Bosses that take that attitude might want to consider what harm some low level employee could do with a bomb or guns. The lowest guy in the food chain could easily kill off upper management. So who gives the floor cleaner or the gal Friday a golden parachute? Or is it only financial loss that must be prevented?

  • Multiple Backdoors (Score:5, Interesting)

    by Bryansix (761547) on Tuesday August 24, 2010 @05:50PM (#33362262) Homepage
    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.
    • Re: (Score:3, Insightful)

      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.

      • Not every problem employee comes with "Crazy MF With Drug Habit" tattooed on his forehead.
      • Sometimes people lie when you do background checks. They want their problem to become your problem.
      • Your IT guy might be just fine until his wife leaves him for a younger woman who also works for your company.
      • Or, like my experience, the first thing you have to do in your new job is fire the sadistic moron that your predecessor tolerated for years.

      The point being, you don't always "put yourself" in that position.

      • All of those problems could be handled in a variety of ways with a competant HR department.

        • Re: (Score:3, Insightful)

          by greenbird (859670)

          All of those problems could be handled in a variety of ways with a competant HR department.

          Isn't that an oxymoron, even if it was spelled correctly.

          • Re: (Score:3, Insightful)

            by hedwards (940851)
            Not really, HR is generally highly competent, just not at what you think they're there for. Most companies have HR employees specifically so that they can be useless and make it as hard as possible for employees to get there benefits, preferably quitting before they're eligible. Sure it's a dumb way to run a business, but it happens. Usually if there's any corruption in a company it's found in HR first and spreads elsewhere.
    • by Belial6 (794905)
      Thinking that a background check is going to protect you is naive at best.
  • Alot of software opens holds due to poor coding as well.

    And look at printers and Vender pc's running RIP software likely on a os that lagging behind on updates but the Vender does let you / says we will void the printer contract over messing with the software / os on the RIP PC.

  • 2. ???
    3. Profit
  • Non evil stuff may look like logic bombs and if you don't keep track of all of it. How knows what hacks and work around that you will fine and taking them out may just lead to have to call old guy back just to find out how some of the stuff works.

    how meny times do you have have the old come back at X2 X3 X4 times the pay to just to work out stuff that only the people who got layed off know about?

  • by ei4anb (625481) on Tuesday August 24, 2010 @06:04PM (#33362464)
    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.
    • Re: (Score:3, Insightful)

      by jjohnson (62583)

      That's a really good catch. Well done.

    • by grahamsaa (1287732) on Tuesday August 24, 2010 @06:48PM (#33362938)
      He knew how to program a logic bomb and how to cover his tracks by removing it from the source, but he didn't have the smarts to change the source file's time stamp? Sounds like an obvious step to take -- not that I'd ever do anything like that, but seriously, changing a time stamp isn't rocket science.
    • by twebb72 (903169) on Tuesday August 24, 2010 @07:17PM (#33363294)

      The worst logic bomb I had to deal with was written similarly by an underpaid (debatable) programmer. He set it up so that when money was exchanged between accounts the program would then truncate the remainder. This, in fact, was only a fraction of a cent. Then he took that remainder (once it had accumulated a bit) and transfer it out into a bank account of his own. As it turns out, it was relatively easy to install.

      We were so far behind for the Y2K updates, most people simply didn't notice. A couple days later the building burned down.

  • Some backdoors are hard to get rid of

    Reflections on Trusting Trust http://cm.bell-labs.com/who/ken/trust.html [bell-labs.com]

    • by trb (8509)
      Yep, exactly what I thought of when I saw this "backdoors" article. "Trusting Trust" was Ken's acceptance speech for the ACM's 1983 Turing award, and described hacking that he had contemplated before then (i.e., more than 25 years ago).
  • ... don't hire sysadmins who act unprofessionally or criminally under duress, and then treat them like professionals, like everyone else.

    I haven't seen any reason to think that IT staff would be more likely to do such harm than anyone else. Sure, maybe they have easier means to effect harm than your average employee, but they have no more motivation nor mind to do so.

  • by Anonymous Coward on Tuesday August 24, 2010 @06:26PM (#33362692)

    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...

  • ... but if you go around assuming you've been rooted by everyone your company has let go, pretty soon your cycles will be consumed by constant self-evaluation. The result would likely be catastrophic money and time loss, akin to the South Park episode where San Francisco disappeared entirely up its own asshole.

  • by bugs2squash (1132591) on Tuesday August 24, 2010 @06:33PM (#33362786)
    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.
    • Re: (Score:3, Informative)

      by sabt-pestnu (967671)

      Wrote the answer to that above, before I saw your post here. To repeat: if it's a hostile environment, you need your own CYA audit, with witnesses. Your replacement could be Evil, or simply Incompetent. And either way, you don't want the blame falling on you.

  • Verify that no keylogger is installed in any computer used to login to other systems
  • Has to be said (Score:5, Insightful)

    by Dunbal (464142) * on Tuesday August 24, 2010 @06:53PM (#33362994)

    You get what you pay for. You hire for the lowest possible salary and treat your professionals like unskilled laborers, well, don't be surprised. A professional would never dream of doing something like this - but then again a professional would not work for peanuts either.

  • by happyhamster (134378) on Tuesday August 24, 2010 @06:59PM (#33363060)

    How about a radical idea of treating employees as people, with respect and dignity, and they will treat you likewise in return? I know I'm stepping a little above the topic, as you asked what to do when you do fire people suddenly without a cause. Please bear with me and don't "escort me out" yet. The way employees are treated in the U.S nowadays is despicable. It would be unacceptable just a few decades ago in this very country, and it is still unacceptable in many parts of the world. An executive firing employees without good cause would and should be roughed up good after work to freshen their understanding of "immoral". American society should make it socially unacceptable, with after-work consequences, to fire people without a good cause, regardless of "laws' bought by corporations in the last decades.

  • Why the nastiness ? (Score:3, Interesting)

    by redelm (54142) on Tuesday August 24, 2010 @07:19PM (#33363320) Homepage

    Nastiness is usually a sign of guilt: "It is human nature to hate those we have wronged [sic]" Tacitus.

    If the corp is nasty, it will attract further nasties and have to cope with the results. The nice people leave.

    If a nice corp has to fire someone for gross malfeasance and such yet cannot charge them, then perhaps send in a trusted senior specialist to check things out quietly. A big investigative purge will just tell everyone there you don't trust them. Then why should they trust you? Thieves have the best locks. Lots of moves in this chessgame.

  • Let me correct that (Score:3, Interesting)

    by drolli (522659) on Tuesday August 24, 2010 @09:24PM (#33364370) Journal

    The assumption should be that you have been rooted by somebody who knows exactly what things are logged in your systems, possibly with continuous influence on what is being logged and how long, maybe even with the power to alter log files. IMHO one of the important things is to use several servers just for logs, to whom only a single admin has access. If one of them is going in a bad way, then you have at least the logs on the other machine. If you are paranoid, transfer the md5 checksums of the files on your servers to these machines and use git on the etc directory, backing the etc directories up on these machines. and force the it staff to make builds of custom SW automated.

    This means you have
    a) logs of what has happened (at least you know what you know)
    b) a possibility to determine which files changed
    c) a documentation about which configuration changes have been done for which purpose.
    d) a backup of the configuration, enabling you to reinstall the machine
    e) a way to rebuild programs added to the system easily.

If I have not seen so far it is because I stood in giant's footsteps.

Working...